On October 14, 2015 at 1:37:05 PM, Nathaniel Smith ([email protected]) wrote:
On Oct 14, 2015 10:04 AM, "Ionel Cristian Mărieș" <[email protected]> wrote:
>
>
> On Wed, Oct 14, 2015 at 7:43 PM, Chris Barker <[email protected]> wrote:
>>
>> some packages were unable to work with the postN suffix.
>
>
> Can you elaborate a bit more here?
>
Apparently some packages were making assumptions about the format of the
numpy.__version__ string, and having .postN in there caused errors when they
tried to process it. (It would be helpful if there were a little permissively
licensed standalone implementation of PEP 440 comparisons, suitable for the "if
pkg.version > ...:" checks that people insist on doing -- I couldn't find one
in some quick searches.)
https://github.com/pypa/packaging
It’s what both pip and setuptools use (though we embed it, but it’s fine to
depend on it too).
IIUC, the specific problems numpy ran into that caused the creation of .postN
releases were:
- oops, didn't sign the uploads, re-upload identical file with proper signature
attached -> not allowed. (I'm not sure if these were embedded or detached
signatures. Either way it'd be nice if pypi allowed it, but for embedded
signatures in particular I can see how this might be a hassle.)
I don’t think we allow embedded signatures, it would be reasonable to allow
uploading detached signatures after the fact though.
- our OS X maintainer tried to use twine to upload OS X wheels for the existing
release; instead it created a new release. Not sure if a bug was filed on
twine, but if not then one probably should be. As a workaround our release docs
now say "always upload wheels by hand using the web interface, never use
setup.py upload or twine".
This shouldn’t create a new release unless you’ve changed the version number
(including adding post releases). If you can reproduce on Test PyPI I can fix
it.
My feeling is that pypi is correct to disallow the mutation of releases once
they become public, but that the ergonomics around this could probably be
improved :-). A more general solution that might be nice to have Someday would
be if you could upload a release in one step, and then get a private link to
poke at what was uploaded and make sure it looks correct, before making it
public in a second step.
The ergonomics of it is pretty bad. Once we kill PyPI legacy and Warehouse is
the thing we’re using, improving things like that will be a lot simpler.
CC'ing the release manager and OS X maintainer in question, in case I got
something wrong or more details are wanted...
-n
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
