Donald Stufft schreef op 15-12-14 13:20:
On Dec 15, 2014, at 6:03 AM, Robin Becker <[email protected]> wrote:
A bitbucket user informs me angrily that he cannot use the version of reportlab
that's latest on pypi because it has a dependency
pillow==2.0.0,>=2.4.0
which is now treated as an 'and' condition by setuptools 8.0 so can not be
satisfied.
In our latest code we have removed the '==2.0.0,', but presumably there's
nothing I can do to make the situation less broken for older versions other
than remove those from pypi.
Unfortunately we had this as part of the install_requires as
install_requires=['pillow ==2.0.0, >=2.4.0','pip>=1.4.1', 'setuptools>=2.2']
so it's our fault for being too lax in describing the requirement. Presumably
the , in the list was always an 'and' and now the ',' in the elements is also :(
Historically the meaning of a comma inside of a version specifier is… well
complicated. Honestly I have a hard time even putting into words what a comma
means at all in a historical context. Sometimes it acts as an OR, sometimes it
acts as and AND, and sometimes it acts as something else that I can’t quite
explain.
This was part of how setuptools was designed, it valued giving an answer, any
answer, over saying “Sorry this doesn’t make sense”. You can see this most
clearly in the version parsing code which would allow versions such as “dog” or
“this isn’t a version but setuptools will parse it as one”. In PEP 440 we
attempted to standardize what a version and what a specifier means, and as part
of that we made the decision that we are going to be stricter in what we
accept. This means that some things that used to be valid versions are no
longer valid versions and in your case, relying on the old, complicated
behavior, of a comma that sometimes means different things.
So yea, in a PEP 440 world the comma is AND.
Sounds sane.
But I now run into unexpected behaviour when two packages have a
constraint on the same third package. For example one has
'zest.releaser==3.50' and another has 'zest.releaser>=3.40'. Wanted and
expected behaviour is to get 3.50, as that satisfies both constraints.
You can test this in a virtualenv with setuptools 8.0.2:
$ pip install 'zest.releaser==3.50,>=3.40'
Downloading/unpacking zest.releaser>=3.40,==3.50
Downloading zest.releaser-3.53.2.zip
...
So expected is 3.50, but you get the latest version, currently 3.53.2.
Sound like a bug?
Where I am seeing this error in practice is in a buildout. I have not
managed to reproduce my error in a small enough buildout that is sane to
share. But for the idea, it goes like this. Latest
buildout-bootstrap.py gives me zc.buildout 2.3.0 and setuptools 0.8.2.
The buildout config has pinned zc.buildout to version 2.2.5 and
setuptools to 7.0 and allow-picked-versions to false. Then I run
bin/buildout. It fails with:
While:
Installing.
Getting section _mr.developer.
Initializing section _mr.developer.
Installing recipe zc.recipe.egg.
Getting distribution for 'zc.buildout==2.2.5,>=1.5.0'.
Error: Picked: zc.buildout = 2.2.5
So one package (zc.recipe egg 1.3.2, but similar with latest 2.0.1) has
a dependency on zc.buildout>=1.5.0 and the buildout config pins
zc.buildout to 2.2.5 and this somehow fails.
Oddly enough, it goed alright when I set allow-picked-versions to true...
For the record, it then goes wrong later with an error that indicates a
casualty of the more strict version checking:
The constraint, 2.0.5, is not consistent with the requirement,
'five.localsitemanager>2.0dev'.
While:
Installing zeoclient.
Error: Bad constraint 2.0.5 five.localsitemanager>2.0dev
The bad constraint '>2.0dev' is in the five.grok package. I guess it
should have been '>2.0.dev0' (or by now simply '>=2.0'). I'll pick it
up for that package.
--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
