[all][tc] Dropping lower-constraints testing from all projects

Jeremy Stanley fungi at yuggoth.org
Thu Jan 21 14:50:12 UTC 2021


On 2021-01-21 09:30:19 +0000 (+0000), Stephen Finucane wrote:
[...]
> What we have doesn't work, and direct dependencies are the only
> things we can truly control. In the scenario you're suggesting,
> not only do we need to track dependencies, but we also need to
> track the dependencies of dependencies, and the dependencies of
> the dependencies of the dependencies, and the dependencies of the
> dependencies of the dependencies of the dependencies etc. etc.
> down the rabbit hole. For each of these indirect dependencies, of
> which there may be many, we need to figure out what the minimum
> version is for each of these indirect dependencies is manually,
> because as has been noted many times there is no standardized
> machinery in place in pip etc. to find (and test) the minimum
> dependency versions supported by a package. Put another way, if we
> depend on package foo, which depends on package bar, which depends
> on package baz, we can state our own informed minimum version for
> foo, but we will need to inspect foo to find a minimum version of
> bar that is suitable, and we will need to inspect baz to find a
> minimum version of baz that is suitable. An impossible ask.
[...]

Where this begins to fall apart, as I mentioned earlier, is that the
larger your transitive dependency set, the more likely it is that a
direct dependency is *also* an indirect dependency (maybe many
layers down). If a dependency of your dependency updates to a
version which insists on a newer version of some other direct
dependency of yours than what you've set in lower-constraints.txt,
then your jobs are going to break and need lower bounds adjustments
or additional indirect dependencies added to the
lower-constraints.txt to roll them back to versions which worked
with the others you've set. Unlike upper-constraints.txt where it's
assumed that a complete transitive set of dependencies is covered,
this will mean additional churn in your stable branches over time.

Or is the idea that we would only every do lower bounds checking on
the release under development, and then remove those jobs when we
branch?
-- 
Jeremy Stanley
-------------- 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-discuss/attachments/20210121/c1607897/attachment.sig>


More information about the openstack-discuss mailing list