Open Stack

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.

-- 
Matthew Thode (prometheanfire)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180315/0d4b2041/attachment.sig>