On Dec 16, 2014, at 2:24 AM, anatoly techtonik
wrote: On Tue, Dec 16, 2014 at 9:45 AM, Donald Stufft
wrote: On Dec 16, 2014, at 1:42 AM, anatoly techtonik
wrote: On Tue, Dec 16, 2014 at 2:48 AM, Donald Stufft
wrote: On Dec 15, 2014, at 6:46 PM, Maurits van Rees
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.
Openstack won’t be providing one, they are adapting server to PEP 440 syntax. If you want to go elsewhere be my guest. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA