[Distutils] setuptools 8 changes are great, but ...

[anatoly techtonik]

On Tue, Dec 16, 2014 at 2:48 AM, Donald Stufft <donald at stufft.io> wrote:
>> On Dec 15, 2014, at 6:46 PM, Maurits van Rees <m.van.rees at zestsoftware.nl> wrote:
>>
>> Maurits van Rees schreef op 15-12-14 23:50:
>>> TMP2/setuptools-8.0.4-py2.7.egg/pkg_resources.py:2425: RuntimeWarning:
>>> 'zc.buildout-2.3.0 ()' is being parsed as a legacy, non PEP 440,
>>> version. You may find odd behavior and sort order. In particular it will
>>> be sorted as less than 0.0. It is recommend to migrate to PEP 440
>>> compatible versions.
>>
>> Actually, I have configured zc.buildout to use a download-cache directory where it saves downloaded zips/tarballs/eggs from PyPI. Buildout then adds this directory as a find-link and setuptools calls package_index.scan_url on it.  This prints the warnings, because it sees for example a file
>> '/Users/mauritsvanrees/cached-downloads/dist/Acquisition-2.13.8.zip'
>> This gets parsed as a Distribution with project_name 'Acquisition-2.13.8' and an empty version.
>>
>> Ah, a demo with plain setuptools 0.8.4 is easy to setup:
>>
>> $ mkdir bar
>> $ touch bar/project-1.0.zip
>> $ . bin/activate
>> (venv) $ python
>> Python 2.7.8 (default, Jul 28 2014, 10:41:45)
>> [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> from setuptools import package_index
>> >>> pi = package_index.PackageIndex()
>> >>> pi.add_find_links(['bar'])
>> /Users/mauritsvanrees/tmp/venv/lib/python2.7/site-packages/pkg_resources.py:2425: RuntimeWarning: 'project-1.0 ()' is being parsed as a legacy, non PEP 440, version. You may find odd behavior and sort order. In particular it will be sorted as less than 0.0. It is recommend to migrate to PEP 440 compatible versions.
>>  RuntimeWarning,
>> >>>
>
> Ah, this is probably an issue with how I detected a legacy version and how setuptools parses a filename. I can probably get rid of the warning spam.


I'd like to opt-out from PEP440 and use semantic versioning (that is
incompatible with PEP440) for my Python packages. I think
pip/setuptools/whatever should not stay in the way and give authors
ability to choose versioning strategy that is most suitable for their
workflow.

To achieve this:
1. pip/setuptools needs to be aware of different versioning strategies
2. package needs to convey which versioning strategy it uses
3. pip/setuptools needs a documented requirement for versions semantic
(what it understands about versions and how it uses them)

For example of the above - pip could document that it doesn't install
development and alpha versions unless explicitly requested with
command line switch, and instead of taking users to read gory details
of PEP440 just mention how package may tell pip that it is alpha or
development.

Previous vague attempt to request the same thing
https://github.com/pypa/pip/issues/1557 (just for the history)
-- 
anatoly t.