> On Dec 16, 2014, at 1:42 AM, anatoly techtonik <[email protected]> wrote: > > On Tue, Dec 16, 2014 at 2:48 AM, Donald Stufft <[email protected]> wrote: >>> On Dec 15, 2014, at 6:46 PM, Maurits van Rees <[email protected]> >>> 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.
It’s not going to happen, it can’t happen reasonably. Luckily though it’s quite trivial for an author to adapt semver to work with PEP 440 syntax. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
