Re: [openstack-dev] [requirements] dependencies problem on different release
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
Re: [openstack-dev] [requirements] dependencies problem on different release
Gareth, 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? Install everything in virtualenv (or at least Rally) Best regards, Boris Pavlovic On Wed, Aug 26, 2015 at 7:00 AM, 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. 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? -- 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 __ 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
[openstack-dev] [requirements] dependencies problem on different release
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. 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? -- 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
Re: [openstack-dev] [requirements] dependencies problem on different release
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
