Open Stack

Excerpts from Thierry Carrez's message of 2018-03-15 14:34:50 +0100:
> Doug Hellmann wrote:
> > [...]
> > TL;DR
> > -----
> > 
> > Let's stop copying exact dependency specifications into all our
> > projects to allow them to reflect the actual versions of things
> > they depend on. The constraints system in pip makes this change
> > safe. We still need to maintain some level of compatibility, so the
> > existing requirements-check job (run for changes to requirements.txt
> > within each repo) will change a bit rather than going away completely.
> > We can enable unit test jobs to verify the lower constraint settings
> > at the same time that we're doing the other work.
> 
> Thanks for the very detailed plan, Doug. It all makes sense to me,
> although I have a precision question (see below).
> 
> > [...]
> >    We also need to change requirements-check to look at the exclusions
> >    to ensure they all appear in the global-requirements.txt list
> >    (the local list needs to be a subset of the global list, but
> >    does not have to match it exactly). We can't have one project
> >    excluding a version that others do not, because we could then
> >    end up with a conflict with the upper constraints list that could
> >    wedge the gate as we had happen in the past.
> > [...]
> > 2. We should stop syncing dependencies by turning off the
> >    propose-update-requirements job entirely.
> > 
> >    Turning off the job will stop the bot from proposing more
> >    dependency updates to projects.
> > [...]
> > After these 3 steps are done, the requirements team will continue
> > to maintain the global-requirements.txt and upper-constraints.txt
> > files, as before. Adding a new dependency to a project will still
> > involve a review step to add it to the global list so we can monitor
> > licensing, duplication, python 3 support, etc. But adjusting the
> > version numbers once that dependency is in the global list will be
> > easier.
> 
> How would you set up an exclusion in that new world order ? We used to
> add it to the global-requirements file and the bot would automatically
> sync it to various consuming projects.
> 
> Now since any exclusion needs to also appear on the global file, you
> would push it first in the global-requirements, then to the project
> itself, is that correct ? In the end the global-requirements file would
> only contain those exclusions, right ?
> 

The first step would need to be adding it to the global-requirements.txt
list. After that, it would depend on how picky we want to be. If the
upper-constraints.txt list is successfully updated to avoid the release,
we might not need anything in the project. If the project wants to
provide detailed guidance about compatibility, then they could add the
exclusion. For example, if a version of oslo.config breaks cinder but
not nova, we might only put the exclusion in global-requirements.txt and
the requirements.txt for cinder.

Doug