Open Stack

Excerpts from Matthew Thode's message of 2018-03-15 10:05:50 -0500:
> On 18-03-15 09:45:38, Doug Hellmann wrote:
> > 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.
> > 
> 
> I wonder if we'd be able to have projects decide via a flag in their tox
> or zuul config if they'd like to opt into auto-updating exclusions only.
> 

We could just change the job that does the sync and use the existing
projects.txt file, couldn't we?

Doug