On October 14, 2015 at 2:25:31 PM, Nathaniel Smith (email@example.com) wrote:
On Oct 14, 2015 11:12 AM, "Donald Stufft" 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.)
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.
I suspect it’d be trivial to relicense it. There’s a total of 6 contributors and I think I know how to get ahold of all of them.
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?
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA