[openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

Joshua Harlow harlowja at yahoo-inc.com
Wed Jul 10 22:06:50 UTC 2013

A useful tool that anvil has built into it (thanks to aababilov). It might
be useful in this situation.


It might be useful to use said tool (or a derivative) to detect this kind
of version conflict earlier rather than later??

It is used in anvil to determine the same set of conflicts so that later
when multiple single packages of openstack (say of a given release) that
said multiple packages will all play nicely together (at least with
respect to pip requirement versioning).


On 7/10/13 2:42 PM, "Sean Dague" <sean at dague.net> wrote:

>Yesterday in the very exciting run around to figure out why the gate was
>broken, we realized something interesting. Because of the way the gate
>process pip requirements (one project at a time), on a current gate run
>we actually install and uninstall python-keystoneclient 4 times in a
>normal run, flipping back and forth from HEAD to 0.2.5.
>http://paste.openstack.org/show/39880/ - shows what's going on
>The net of this means that if any of the projects specify a capped
>client, it has the potential for preventing that client from being
>tested in the gate. This is very possibly part of the reason we ended up
>with a broken python-keystoneclient 0.3.0 released.
>I think we need to get strict on projects and prevent them from capping
>their client requirements. That will also put burden on clients that
>they don't break backwards compatibility (which I think was a goal
>regardless). However there is probably going to be a bit of pain getting
>from where we are today, to this world.
>This is both a heads up, and a time for discussion, before we start
>figuring out how to make this better in the gate.
>	-Sean
>Sean Dague
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list