[Distutils] change in setuptools 8.0

[Maurits van Rees]

Donald Stufft schreef op 15-12-14 13:20:
>
>> On Dec 15, 2014, at 6:03 AM, Robin Becker <robin at reportlab.com> 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