[openstack-dev] [requirements] dependencies problem on different release
Robert Collins
robertc at robertcollins.net
Wed Aug 26 19:32:23 UTC 2015
On 27 August 2015 at 02:00, Gareth <academicgareth at gmail.com> wrote:
> Hey guys,
>
> I have a question about dependencies. There is an example:
>
> On 2014.1, project A is released with its dependency in requirements.txt
> which contains:
>
> foo>=1.5.0
> bar>=2.0.0,<2.2.0
>
> and half a year later, the requirements.txt changes to:
>
> foo>=1.7.0
> bar>=2.1.0,<2.2.0
>
> It looks fine, but potential change would be upstream version of package foo
> and bar become 2.0.0 and 3.0.0 (major version upgrade means there are
> incompatible changes).
>
> For bar, there will be no problems, because "<2.2.0" limit the version from
> major version changes. But with 2.0.0 foo, it will break the installation of
> 2014.1 A, because current development can't predict every incompatible
> changes in the future.
Correct. But actually bar is a real problem for single-instance binary
distributors - like Debian family distributions - where only one
version of bar can be in the archive at once. For those distributions,
when bar 3 comes out, they cannot add it to the archive until a new
release of project A happens (or they break project A). They also
can't add anything to the archive that depends on bar > 2.2.0, because
they can't add bar. So it leads to gridlock. We are now avoiding
adding and won't except in exceptional circumstances, such defensive
upper bounds to OpenStack's requirements. When we /know/ that the
thing is broken we may - if we can't get it fixed.
> A real example is to enable Rally for OpenStack Juno. Rally doesn't support
> old release officially but I could checkout its codes to the Juno release
> date which make both codes match. However even if I use the old
> requirements.txt to install dependencies, there must be many packages are
> installed as upstream versions and some of them breaks. An ugly way is to
> copy pip list from old Juno environment and install those properly. I hope
> there are better ways to do this work. Anyone has smart ideas?
As Boris says, use virtualenvs. They'll solve 90% of the pain.
-Rob
--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
More information about the OpenStack-dev
mailing list