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)
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
