how to register with pypi - no such setup.py

[Phlip]

And the next question in the series - how to make sure the resulting
package has a setup.py file?

The basic steps are...

- build a python package
- create a minimal setup.py
- (github it, natch)
- throw it at pypi with:
python setup.py bdist upload
- attempt to install it with:
sudo pip install my_package

and get this:

Downloading/unpacking my_package

...
IOError: [Errno 2] No such file or directory: '.../setup.py'

So the irony is if I had to use setup.py to build the
MyPackage..tar.gz, why isn't it inside it?

Any tips?

(the actual package name is censored because I don't need people
finding this if they google for that!

(and this is a repost because I can't see my admittedly off-topic
question on the newsgroup)

 

[Martin v. Loewis]

Any tips?

A binary distribution won't have a setup.py, because
you can install it by other means (such as Windows Installer),
instead of running setup.py

What you want is a source distribution (sdist).

Even if you want to create a binary distribution, don't use the
bdist command, but some specialization, such as bdist_rpm.

Regards,
Martin

 

[Phlip]

A binary distribution won't have a setup.py, because
you can install it by other means (such as Windows Installer),
instead of running setup.py

What you want is a source distribution (sdist).

Thanks. Yes, this is prob'ly documented somewhere.

Now my next problem - how to get pypi.python.org to stop burning up
version numbers each time I test this?

 

[Martin v. Loewis]

Thanks. Yes, this is prob'ly documented somewhere.

Now my next problem - how to get pypi.python.org to stop burning up
version numbers each time I test this?

I don't speak English well enough to understand what "to burn up"
means - to my knowledge, PyPI does no such thing.

What are you doing, what is happening, and what do you expect to
happen instead?

Regards,
Martin

 

[Phlip]

I don't speak English well enough to understand what "to burn up"
means - to my knowledge, PyPI does no such thing.

I don't know how to test pypi on my own notebook.

Each time I change setup.py or something, if I want to test my change,
I have to boost the version number, and then use sdist upload to push
a new version to the server.

This means I am using up perfectly good version numbers. If I don't
change the number, I get a condescending message "Upload failed (400):
A file named "Morelia-0.0.10.tar.gz" already exists for
Morelia-0.0.10. To fix problems with that file you should create a new
release."

I have no alternative, to fix bugs in PyPi, _not_ in "that file", but
to continue burning up version numbers that nobody cares about. The
message is condescending because I am aware of the reason we version
packages, and the message is _not_ helping me apply that reason!

 

[Phlip]

I have no alternative, to fix bugs in PyPi, _not_ in "that file", but

to continue burning up version numbers that nobody cares about. The
message is condescending because I am aware of the reason we version
packages, and the message is _not_ helping me apply that reason!

Aaand I just found the Remove button, so the complaint is down to a
misleading error message!

 

[Stefan Krah]

I don't know how to test pypi on my own notebook.

Each time I change setup.py or something, if I want to test my change,

^^^^^^^^^^^^^^^^^

This means I am using up perfectly good version numbers. If I don't
change the number, I get a condescending message "Upload failed (400):
A file named "Morelia-0.0.10.tar.gz" already exists for
Morelia-0.0.10. To fix problems with that file you should create a new
release."

It is quite reasonable that changed archives with the same version number
are not accepted. Very helpful, not condescending.


Stefan Krah

 

[Diez B. Roggisch]

Aaand I just found the Remove button, so the complaint is down to a
misleading error message!

It's not misleading. It precisely states what's the reason for the
denial of the request, and it's a good reason for that matter.

I agree that a kind of sandbox environment to test PyPI-packaging would
be nice, but in lieu of that, you'll have to stick with removing &
re-creating - or bumping up versions. Which, btw, is *not* to hard if
you do e.g.

0.1.1234

where 1234 is an increasing number. Just for testing.

Diez

 

[Phlip]

It is quite reasonable that changed archives with the same version number
are not accepted. Very helpful, not condescending.

The message helps you remember to bump your version number. Try:

"Please either increment your version number, or use your Package
Editing page to delete the release"

The current message implies I have problems with my library, but don't
know that problems with libraries are what version numbers are for...