We've had a number of bugs recently that can be tracked back to older
pbr and setuptools versions being used.
The reason this happens is that we have a policy that we *don't*
version the setup_requires pbr dependency.
However, I've been looking into this, and I've only been able to find
two bugs around this:
A) setuptools can't handle an installed-but-not-satisfied
setup_requires dependency.
B) setuptools can't upgrade setuptools itself
Imagine we have
setup(pbr=True, setup_requires='pbr>=1.3')
in setup.py.
If:
pbr 1.0.0 is installed, python setup.py install will error.
pbr 1.3+ is installed, python setup.py install will use it
pbr is not installed and pbr 1.3+ is in a .eggs directory, python
setup.py install will use it
pbr is not installed, python setup.py install will use easy_install to
put latest in a .eggs directory.
Now consider
setup(pbr=True, setup_requires='pbr')
# But we still actually need 1.3
If:
pbr 1.0.0 is installed, python setup.py install will fail
pbr 1.3+ is installed, python setup.py install will use it
pbr is not installed and pbr 1.3+ is in a .eggs directory, python
setup.py install will use it
pbr is not installed, python setup.py install will use easy_install to
put latest in a .eggs directory.
You can see that other than changing from a setuptools detected error
to a random failure, that the behaviours are the same.
AIUI we previously tried
setup_requires=['d2to1>=0.2.10,<0.3', 'pbr>=0.5,<0.6'],
Which will run into bug A when we release a new pbr outside that range
and install it: any existing projects will be hard broken.
But - I think we learnt two lessons there:
i- pbr can't do behaviour breaks ever
ii- upper bounds on setup_requires cause paradoxes during transitions
and make it impossible to install a devstack.
Our solution to ii was to drop both the upper and lower bounds, but
AFAICT this was incorrect: we should have dropped only the upper
bound, since it was a conservative guess ('what if we break API in
pbr') but the lower bound is an actual statement('things are known
broken with earlier than this version').
If we add a lower bound back in, we'll get better signalling of the
issue to users (but not perfect), and certainly if folk look at the
metadata they will be able to infer the right answer.
Since all our current releases of things are unbounded, there's no
immediate wedge that we'd create by adding this.
https://review.openstack.org/200758
-Rob
--
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
