On Tue, Dec 16, 2014 at 9:45 AM, Donald Stufft <[email protected]> wrote: >> 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.
Or move to other distribution method than PyPI FWIW. If OpenStack ecosystem could be able to provide an alternative, I'd gladly switch. There are already too many packaging bicycles out there for dynamic languages - Ruby, npm, PyPI - but in fact the only difference that people need for server side of this stuff is distinctive design and URL/subdomain. -- anatoly t. _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
