Open Stack

Excerpts from Jeremy Stanley's message of 2018-03-15 14:28:49 +0000:
> 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

That second case is what this prevents. There's a race condition between
updating the requirements range (and exclusions) in a project tree and
updating the upper-constraints.txt list. The check forces those lists to
be updated in an order that avoids a case where the version in
constraints is not compatible with an app installed in an integration
test job.

> 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?).

Yes, those are all good failure cases that this prevents, too.

> >    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.

The lack of testing is an issue, but the tight coupling of those
lower bounds is a bigger problem to me. I know that distros don't
necessarily package exactly what we have in the upper-constraints.txt
list, but they're doing their own testing with those alternatives.

> 
> > 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

Yes, Dirk did that work.

> 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.

Right. The fact that the values aren't necessarily accurate won't
be affected by the change to stop syncing, and the additional unit
tests should help us catch at least some of the issues.

Doug