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 :(
On Dec 15, 2014, at 6:03 AM, Robin Becker robin@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.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Donald Stufft schreef op 15-12-14 13:20:
On Dec 15, 2014, at 6:03 AM, Robin Becker robin@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.
On Dec 15, 2014, at 9:05 AM, Maurits van Rees m.van.rees@zestsoftware.nl wrote:
Donald Stufft schreef op 15-12-14 13:20:
On Dec 15, 2014, at 6:03 AM, Robin Becker robin@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?
Try with the develop version of pip. pip bundles setuptools internally in order to prevent issues from setuptools accidentally getting uninstalled breaking pip and such,
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.
I don’t know much (or anything really) about buildout or what it does with that.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Mon, Dec 15, 2014 at 12:26 PM, Donald Stufft donald@stufft.io wrote:
On Dec 15, 2014, at 9:05 AM, Maurits van Rees m.van.rees@zestsoftware.nl wrote:
Donald Stufft schreef op 15-12-14 13:20:
On Dec 15, 2014, at 6:03 AM, Robin Becker robin@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?
Try with the develop version of pip. pip bundles setuptools internally in order to prevent issues from setuptools accidentally getting uninstalled breaking pip and such,
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.
I don’t know much (or anything really) about buildout or what it does with that.
Buildout doesn't try to merge dependency requirements from different packages. It just installs packages and their dependencies and builds up a working set.
It does merge constraints from the versions section (if any) with whatever requirement it's working on at any point in time.
I'm guessing that the requirement: zc.buildout==2.2.5,>=1.5.0 is coming from a setup spec or from some buildout section. It was a valid spec once but isn't any more.
Buildout 2 before 2.3 did a lot of strange gymnastics to try to merge version constraints with requirement specs given the strange old rules.
Now, with the new sane rules, it just adds the constraint to the whatever existing spec is in the requirement.
There error "Bad constraint 2.0.5 five.localsitemanager>2.0dev" looks to me like a bug. :) When buildout gets a single-version constraint, like 2.0.5, it tests whether that version is "in" (__contains__) a requirement.
import pkg_resources r = pkg_resources.Requirement.parse("five.localsitemanager>2.0dev") '2.0.5' in r
False
r = pkg_resources.Requirement.parse("five.localsitemanager>2.0.dev0") '2.0.5' in r
True
I have a feeling the definition of "dev" has changed too.
Jim
On Dec 15, 2014, at 1:15 PM, Jim Fulton jim@zope.com wrote:
import pkg_resources r = pkg_resources.Requirement.parse("five.localsitemanager>2.0dev") '2.0.5' in r
False
r = pkg_resources.Requirement.parse("five.localsitemanager>2.0.dev0") '2.0.5' in r
True
I have a feeling the definition of "dev" has changed too.
I think this is a bug with the packaging lib that has to do with the fact that the “>2.0dev” doesn’t have a . separating it. Taking a look at it now.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Dec 15, 2014, at 1:26 PM, Donald Stufft donald@stufft.io wrote:
On Dec 15, 2014, at 1:15 PM, Jim Fulton jim@zope.com wrote:
import pkg_resources r = pkg_resources.Requirement.parse("five.localsitemanager>2.0dev") '2.0.5' in r
False
r = pkg_resources.Requirement.parse("five.localsitemanager>2.0.dev0") '2.0.5' in r
True
I have a feeling the definition of "dev" has changed too.
I think this is a bug with the packaging lib that has to do with the fact that the “>2.0dev” doesn’t have a . separating it. Taking a look at it now.
Found the bug, it’s fixed in the packaging lib here: https://github.com/pypa/packaging/pull/18
Will get that merged once tests passed and a new release out and a PR to setuptools.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
A new setuptools release is out that should fix the 2.0.5 in dev bug.
On Dec 15, 2014, at 1:44 PM, Donald Stufft donald@stufft.io wrote:
On Dec 15, 2014, at 1:26 PM, Donald Stufft donald@stufft.io wrote:
On Dec 15, 2014, at 1:15 PM, Jim Fulton jim@zope.com wrote:
import pkg_resources r = pkg_resources.Requirement.parse("five.localsitemanager>2.0dev") '2.0.5' in r
False
r = pkg_resources.Requirement.parse("five.localsitemanager>2.0.dev0") '2.0.5' in r
True
I have a feeling the definition of "dev" has changed too.
I think this is a bug with the packaging lib that has to do with the fact that the “>2.0dev” doesn’t have a . separating it. Taking a look at it now.
Found the bug, it’s fixed in the packaging lib here: https://github.com/pypa/packaging/pull/18
Will get that merged once tests passed and a new release out and a PR to setuptools.
Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Jim Fulton schreef op 15-12-14 19:15:
Buildout doesn't try to merge dependency requirements from different packages. It just installs packages and their dependencies and builds up a working set.
It does merge constraints from the versions section (if any) with whatever requirement it's working on at any point in time.
I'm guessing that the requirement: zc.buildout==2.2.5,>=1.5.0 is coming from a setup spec or from some buildout section. It was a valid spec once but isn't any more.
Let's try a buildout with Plone. This one goes fine (except for possible warnings about legacy versions):
$ curl -O https://bootstrap.pypa.io/bootstrap-buildout.py $ cat buildout.cfg [buildout] extends = http://dist.plone.org/release/4.3-latest/versions.cfg versions = versions parts = instance
[versions] # Override version pins that are in the file of the extends line. zc.buildout = 2.3.0 setuptools = 8.0.4
[instance] recipe = plone.recipe.zope2instance user = admin:admin http-address = 8080 eggs = Plone
$ python bootstrap-buildout.py $ bin/buildout
All is well.
Now edit buildout.cfg and add this line in the [buildout] section:
allow-picked-versions = false
$ bin/buildout ... While: Installing. Getting section instance. Initializing section instance. Installing recipe plone.recipe.zope2instance. Getting distribution for 'ZODB3==3.10.5,>=3.9'. Error: Picked: ZODB3 = 3.10.5
Somehow a problem appears because the buildout config pins ZODB3 to 3.10.5, and buildout installs plone.recipe.zope2instance which requires 'ZODB3 >= 3.9'. (I wonder if this behaviour is specific for recipes, but I guess not.)
Now revert the change, and instead add this line in the [buildout] section:
show-picked-versions = true
$ bin/buildout ... Versions had to be automatically picked. The following part definition lists the versions picked: [versions] AccessControl = 3.0.8 Markdown = 2.0.3 Products.ATContentTypes = 2.1.14 Products.OFSP = 2.13.2 Products.PlonePAS = 4.1.4 ZODB3 = 3.10.5 Zope2 = 2.13.22 archetypes.schemaextender = 2.1.4 collective.z3cform.datetimewidget = 1.2.6 diazo = 1.0.6 lxml = 2.3.6 mechanize = 0.2.5 plone.app.contentmenu = 2.0.10 plone.app.imaging = 1.0.11 plone.app.jquery = 1.7.2 plone.app.linkintegrity = 1.5.5 plone.app.registry = 1.2.3 plone.app.z3cform = 0.7.7 plone.autoform = 1.6.1 plone.behavior = 1.0.2 plone.browserlayer = 2.1.3 plone.dexterity = 2.2.4 plone.keyring = 2.0.1 plone.namedfile = 2.0.7 plone.registry = 1.0.2 plone.resource = 1.0.3 plone.scale = 1.3.4 plone.schemaeditor = 1.3.8 plone.supermodel = 1.2.6 plone.z3cform = 0.8.0 python-gettext = 1.2 python-openid = 2.2.5 repoze.xmliter = 0.5 transaction = 1.1.1 z3c.form = 3.2.1 zope.app.locales = 3.6.2 zope.tales = 3.5.3
All these versions are definitely pinned in the file we extend (or in files that this file extends): http://dist.plone.org/release/4.3-latest/versions.cfg
So: strange behaviour.
On Mon, Dec 15, 2014 at 7:05 PM, Maurits van Rees m.van.rees@zestsoftware.nl wrote:
Jim Fulton schreef op 15-12-14 19:15:
Buildout doesn't try to merge dependency requirements from different packages. It just installs packages and their dependencies and builds up a working set.
It does merge constraints from the versions section (if any) with whatever requirement it's working on at any point in time.
I'm guessing that the requirement: zc.buildout==2.2.5,>=1.5.0 is coming from a setup spec or from some buildout section. It was a valid spec once but isn't any more.
Let's try a buildout with Plone. This one goes fine (except for possible warnings about legacy versions):
$ curl -O https://bootstrap.pypa.io/bootstrap-buildout.py $ cat buildout.cfg [buildout] extends = http://dist.plone.org/release/4.3-latest/versions.cfg versions = versions parts = instance
[versions] # Override version pins that are in the file of the extends line. zc.buildout = 2.3.0 setuptools = 8.0.4
[instance] recipe = plone.recipe.zope2instance user = admin:admin http-address = 8080 eggs = Plone
$ python bootstrap-buildout.py $ bin/buildout
All is well.
Now edit buildout.cfg and add this line in the [buildout] section:
allow-picked-versions = false
$ bin/buildout ... While: Installing. Getting section instance. Initializing section instance. Installing recipe plone.recipe.zope2instance. Getting distribution for 'ZODB3==3.10.5,>=3.9'. Error: Picked: ZODB3 = 3.10.5
Somehow a problem appears because the buildout config pins ZODB3 to 3.10.5, and buildout installs plone.recipe.zope2instance which requires 'ZODB3 >= 3.9'. (I wonder if this behaviour is specific for recipes, but I guess not.)
Now revert the change, and instead add this line in the [buildout] section:
show-picked-versions = true
$ bin/buildout ... Versions had to be automatically picked. The following part definition lists the versions picked: [versions] AccessControl = 3.0.8 Markdown = 2.0.3 Products.ATContentTypes = 2.1.14 Products.OFSP = 2.13.2 Products.PlonePAS = 4.1.4 ZODB3 = 3.10.5 Zope2 = 2.13.22 archetypes.schemaextender = 2.1.4 collective.z3cform.datetimewidget = 1.2.6 diazo = 1.0.6 lxml = 2.3.6 mechanize = 0.2.5 plone.app.contentmenu = 2.0.10 plone.app.imaging = 1.0.11 plone.app.jquery = 1.7.2 plone.app.linkintegrity = 1.5.5 plone.app.registry = 1.2.3 plone.app.z3cform = 0.7.7 plone.autoform = 1.6.1 plone.behavior = 1.0.2 plone.browserlayer = 2.1.3 plone.dexterity = 2.2.4 plone.keyring = 2.0.1 plone.namedfile = 2.0.7 plone.registry = 1.0.2 plone.resource = 1.0.3 plone.scale = 1.3.4 plone.schemaeditor = 1.3.8 plone.supermodel = 1.2.6 plone.z3cform = 0.8.0 python-gettext = 1.2 python-openid = 2.2.5 repoze.xmliter = 0.5 transaction = 1.1.1 z3c.form = 3.2.1 zope.app.locales = 3.6.2 zope.tales = 3.5.3
All these versions are definitely pinned in the file we extend (or in files that this file extends): http://dist.plone.org/release/4.3-latest/versions.cfg
So: strange behaviour.
I'm not sure how this relates to what you reported before, but this is a known bug that I think I introduced on Sunday. I'm about to work on a fix.
Jim
Donald Stufft schreef op 15-12-14 18:26:
On Dec 15, 2014, at 9:05 AM, Maurits van Rees m.van.rees@zestsoftware.nl wrote:
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?
Try with the develop version of pip. pip bundles setuptools internally in order to prevent issues from setuptools accidentally getting uninstalled breaking pip and such,
Ah, that works. Thanks.
(venv)mauritsvanrees@procyon:venv $ pip install https://github.com/pypa/pip/tarball/develop#egg=pip-dev Downloading/unpacking pip-dev from https://github.com/pypa/pip/tarball/develop ... Successfully installed pip-dev Cleaning up... (venv)mauritsvanrees@procyon:venv $ pip --version pip 6.0.dev1 from /Users/mauritsvanrees/tmp/venv/lib/python2.7/site-packages (python 2.7) (venv)mauritsvanrees@procyon:venv $ pip install 'zest.releaser==3.50,>=3.40' Collecting zest.releaser==3.50,>=3.40 Downloading zest.releaser-3.50.zip (124kB) 100% |################################| 126kB 1.1MB/s Requirement already satisfied (use --upgrade to upgrade): setuptools in ./lib/python2.7/site-packages (from zest.releaser==3.50,>=3.40) Installing collected packages: zest.releaser Found existing installation: zest.releaser 3.53.2 Uninstalling zest.releaser: Successfully uninstalled zest.releaser Running setup.py install for zest.releaser Skipping installation of /Users/mauritsvanrees/tmp/venv/lib/python2.7/site-packages/zest/__init__.py (namespace package) Installing /Users/mauritsvanrees/tmp/venv/lib/python2.7/site-packages/zest.releaser-3.50-py2.7-nspkg.pth ... Successfully installed zest.releaser
Great. We're gonna hopefully release pip 6 this week.
On Dec 15, 2014, at 5:27 PM, Maurits van Rees m.van.rees@zestsoftware.nl wrote:
Donald Stufft schreef op 15-12-14 18:26:
On Dec 15, 2014, at 9:05 AM, Maurits van Rees m.van.rees@zestsoftware.nl wrote:
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?
Try with the develop version of pip. pip bundles setuptools internally in order to prevent issues from setuptools accidentally getting uninstalled breaking pip and such,
Ah, that works. Thanks.
(venv)mauritsvanrees@procyon:venv $ pip install https://github.com/pypa/pip/tarball/develop#egg=pip-dev Downloading/unpacking pip-dev from https://github.com/pypa/pip/tarball/develop ... Successfully installed pip-dev Cleaning up... (venv)mauritsvanrees@procyon:venv $ pip --version pip 6.0.dev1 from /Users/mauritsvanrees/tmp/venv/lib/python2.7/site-packages (python 2.7) (venv)mauritsvanrees@procyon:venv $ pip install 'zest.releaser==3.50,>=3.40' Collecting zest.releaser==3.50,>=3.40 Downloading zest.releaser-3.50.zip (124kB) 100% |################################| 126kB 1.1MB/s Requirement already satisfied (use --upgrade to upgrade): setuptools in ./lib/python2.7/site-packages (from zest.releaser==3.50,>=3.40) Installing collected packages: zest.releaser Found existing installation: zest.releaser 3.53.2 Uninstalling zest.releaser: Successfully uninstalled zest.releaser Running setup.py install for zest.releaser Skipping installation of /Users/mauritsvanrees/tmp/venv/lib/python2.7/site-packages/zest/__init__.py (namespace package) Installing /Users/mauritsvanrees/tmp/venv/lib/python2.7/site-packages/zest.releaser-3.50-py2.7-nspkg.pth ... Successfully installed zest.releaser
-- Maurits van Rees: http://maurits.vanrees.org/ Zest Software: http://zestsoftware.nl
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Mon, Dec 15, 2014 at 05:47:09PM -0500, Donald Stufft wrote:
Great. We're gonna hopefully release pip 6 this week.
IIRC I saw it said somewhere that virtualenv's releases are tied to the pip release schedule. In that case I'd like to bring https://github.com/pypa/virtualenv/issues/673 to your attention, because it's a regression that breaks virtualenv -p and therefore tox.
(There are two alternative fixes, PR #674 and PR #672.)
Marius Gedminas
-
Donald Stufft -
Jim Fulton -
Marius Gedminas -
Maurits van Rees -
Robin Becker