Open Stack

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