Re: [openstack-dev] [Horizon][stable][requirements] Modifying global-requirements to cap xstatic package versions
On 03/02/2017 12:57 PM, Doug Hellmann wrote: > Right, friends don't let friends cap dependencies. > > Let's work on getting constraints rolled out where needed instead. This is the basic response I have to this. More specifically it can cause more churn in consuming projects, even if it's done perfectly. If it's not done perfectly we have to deal with untangling the requirements for a security update (or the like). -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature __ 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] [Horizon][stable][requirements] Modifying global-requirements to cap xstatic package versions
Excerpts from Clark Boylan's message of 2017-03-02 10:40:39 -0800: > On Wed, Mar 1, 2017, at 07:10 PM, Richard Jones wrote: > > Hi folks, > > > > We've run into some issues with various folks installing Horizon and > > its dependencies using just requirements.txt which doesn't limit the > > versions of xstatic packages beyond some minimum version. This is a > > particular problem for releases prior to Ocata since those are not > > compatible with the latest versions of some of the xstatic packages. > > So, we believe what's necessary is to: > > > > 1. Update current global-requirements.txt to pin the current released > > version of each xstatic package. We don't update xstatic packages very > > often, so keeping g-r in lock-step with upper-constraints.txt is > > reasonable, I think. > > 2. Update stable versions of global-requirements.txt to restrict them > > to the versions we know are compatible based on the versions in > > upper-constraints for the particular stable release. > > > > > > Thoughts? > > In the time before constraints we tried to manage our dependencies this > way and it just resulted in different headaches. Things like not being > able to pull in bug fixes because caps were too aggressive, needing to > update multiple requirements files all at once due to differing deps > lists in projects as caps got updated, and pip's dependency resolver not > actually resolving the full tree in ways one might expect all caused > problems. > > We are currently seeing similar problems with the new PBR 2.0 release > because PBR is/was capped in many places and is not able to be managed > by constraints. > > All this to say there are known downsides to doing it this way and > constraints is the current solution for dealing with package deps more > sanely. Would it be more effective to better educate folks about > constraints and how it is useful? > > Clark > Right, friends don't let friends cap dependencies. Let's work on getting constraints rolled out where needed instead. Doug __ 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] [Horizon][stable][requirements] Modifying global-requirements to cap xstatic package versions
On Wed, Mar 1, 2017, at 07:10 PM, Richard Jones wrote: > Hi folks, > > We've run into some issues with various folks installing Horizon and > its dependencies using just requirements.txt which doesn't limit the > versions of xstatic packages beyond some minimum version. This is a > particular problem for releases prior to Ocata since those are not > compatible with the latest versions of some of the xstatic packages. > So, we believe what's necessary is to: > > 1. Update current global-requirements.txt to pin the current released > version of each xstatic package. We don't update xstatic packages very > often, so keeping g-r in lock-step with upper-constraints.txt is > reasonable, I think. > 2. Update stable versions of global-requirements.txt to restrict them > to the versions we know are compatible based on the versions in > upper-constraints for the particular stable release. > > > Thoughts? In the time before constraints we tried to manage our dependencies this way and it just resulted in different headaches. Things like not being able to pull in bug fixes because caps were too aggressive, needing to update multiple requirements files all at once due to differing deps lists in projects as caps got updated, and pip's dependency resolver not actually resolving the full tree in ways one might expect all caused problems. We are currently seeing similar problems with the new PBR 2.0 release because PBR is/was capped in many places and is not able to be managed by constraints. All this to say there are known downsides to doing it this way and constraints is the current solution for dealing with package deps more sanely. Would it be more effective to better educate folks about constraints and how it is useful? Clark __ 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] [Horizon][stable][requirements] Modifying global-requirements to cap xstatic package versions
Hi folks, We've run into some issues with various folks installing Horizon and its dependencies using just requirements.txt which doesn't limit the versions of xstatic packages beyond some minimum version. This is a particular problem for releases prior to Ocata since those are not compatible with the latest versions of some of the xstatic packages. So, we believe what's necessary is to: 1. Update current global-requirements.txt to pin the current released version of each xstatic package. We don't update xstatic packages very often, so keeping g-r in lock-step with upper-constraints.txt is reasonable, I think. 2. Update stable versions of global-requirements.txt to restrict them to the versions we know are compatible based on the versions in upper-constraints for the particular stable release. Thoughts? Richard __ 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
