Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180315/627c84fb/attachment.sig>