Hi, On Wed, Oct 14, 2015 at 11:25 AM, Nathaniel Smith <n...@pobox.com> wrote: > On Oct 14, 2015 11:12 AM, "Donald Stufft" <don...@stufft.io> wrote: >> > [...] >>> 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). > > That's under Apache 2, so it can't be used by GPLv2 packages, or any package > that might be used by GPLv2 packages. > >>> >>> 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. > > Matthew? Any thoughts?
Sorry - I'm not sure whether y'all are surprised by the behavior of twine in this situation. Specifically, the situation was: * There was a release on pypi was labeled 1.10.0 : https://pypi.python.org/pypi/numpy/1.10.0; * The source archives that Chuck uploaded were from code that gave a version string of '1.10.0.post2'; * I built wheels from this code, that had this version encoded in the filename - e.g. http://wheels.scikit-image.org/numpy-1.10.0.post2-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl ; * I used `twine upload http://wheels.scikit-image.org/numpy-1.10.0.post2-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl` etc to upload these. When I did this, pypi created a new release called https://pypi.python.org/pypi/numpy/1.10.0.post2 and put the wheels there. I'm guessing that this is what y'all expected? Best, Matthew _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
