On 2018-03-15 07:03:11 -0400 (-0400), Doug Hellmann wrote: [...] > 1. Update the requirements-check test job to change the check for > an exact match to be a check for compatibility with the > upper-constraints.txt value. [...]
I thought it might be possible to even just do away with this job entirely, but some cursory testing shows that if you supply a required versionspec which excludes your constrained version of the same package, you'll still get the constrained version installed even though you indicated it wasn't in your "supported" range. Might be a nice patch to work on upstream in pip, making it explicitly error on such a mismatch (and _then_ we might be able to stop bothering with this job). > 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. [...] At first it seems like this wouldn't end up being necessary; as long as you're not setting an upper bound or excluding the constrained version, there shouldn't be a coinstallability problem right? Though I suppose there are still a couple of potential pitfalls if we don't check exclusions: setting an exclusion for a future version which hasn't been released yet or is otherwise higher than the global upper constraint; situations where we need to roll back a constraint to an earlier version (e.g., we discover a bug in it) and some project has that earlier version excluded. So I suppose there is some merit to centrally coordinating these, making sure we can still pick sane constraints which work for all projects (mental exercise: do we also need to build a tool which can make sure that proposed exclusions don't eliminate all possible version numbers?). > As the minimum > versions of dependencies diverge within projects, there will no > longer *be* a real global set of minimum values. Tracking a list of > "highest minimums", would either require rebuilding the list from the > settings in all projects, or requiring two patches to change the > minimum version of a dependency within a project. [...] It's also been suggested in the past that package maintainers for some distributions relied on the ranges in our global requirements list to determine what the minimum acceptable version of a dependency is so they know whether/when it needs updating (fairly critical when you consider that within a given distro some dependencies may be shared by entirely unrelated software outside our ecosystem and may not be compatible with new versions as soon as we are). On the other hand, we never actually _test_ our lower bounds, so this was to some extent a convenient fiction anyway. > 1. Set up a new tox environment called "lower-constraints" with > base-python set to "python3" and with the deps setting configured > to include a copy of the existing global lower constraints file > from the openstack/requirements repo. [...] I didn't realize lower-constraints.txt already existed (looks like it got added a little over a week ago). Reviewing the log it seems to have been updated based on individual projects' declared minimums so far which seems to make it a questionable starting point for a baseline. I suppose the assumption is that projects have been merging requirements proposals which bump their declared lower-bounds, though experience suggests that this doesn't happen consistently in projects receiving g-r updates today (they will either ignore the syncs or amend them to undo the lower-bounds changes before merging). At any rate, I suppose that's a separate conversation to be had, and as you say it's just a place to start from but projects will be able to change it to whatever values they want at that point. -- Jeremy Stanley
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