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 <robe...@robertcollins.net> wrote: > On 27 August 2015 at 02:00, Gareth <academicgar...@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 <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 > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@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.*
__________________________________________________________________________ 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
