Open Stack

Btw, it's not a dependency conflict issue. If we install python
dependencies via pip, it's okay to be with foo>=1.5.0 in the past, but not
now maybe (oslo.util -> oslo_util breaks nearly everything). Maybe we need
a requirements.txt as release like:

foo==1.5.0
bar==2.1.0

not

for>=1.5.0
bar>=2.0.0

On Thu, Aug 27, 2015 at 3:32 AM, Robert Collins <robertc at robertcollins.net>
wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Gareth

*Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball*
*OpenStack contributor, kun_huang at freenode*
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150827/eee8054b/attachment.html>