Open Stack

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