[Distutils] PyPi not allowing duplicate filenames

[Matthew Brett]

Hi,

On Wed, Oct 14, 2015 at 11:25 AM, Nathaniel Smith <njs at pobox.com> wrote:
> On Oct 14, 2015 11:12 AM, "Donald Stufft" <donald at 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