Hi,

For Windows related projects such as os-win and networking-hyperv,

we decided to keep the lower constraints job but remove indirect

dependencies from the lower-constraints.txt file.

This made it much easier to maintain and it allows us to at least cover

direct dependencies. I suggest considering this approach instead of

completely dropping the lower constraints job, whenever possible.

Another option might be to make it non-voting while it’s getting fixed.

Lucian Petrut

From: Jeremy Stanley
Sent: Wednesday, January 20, 2021 1:52 AM
To: openstack-discuss@lists.openstack.org
Subject: Re: [all][tc] Dropping lower-constraints testing from all projects

On 2021-01-20 00:09:39 +0100 (+0100), Thomas Goirand wrote:

[...]

> Something I don't understand: why can't we use an older version of

> pip, if the problem is the newer pip resolver? Or can't the

> current pip be patched to fix things? It's not as if there was no

> prior art... Maybe I'm missing the big picture?

[...]

To get to the heart of the matter, when using older versions of pip

it was just quietly installing different versions of packages than

we asked it to, and versions of transitive dependencies which

directly conflicted with the versions other dependencies said they

required. When pip finally (very recently) implemented a coherent

dependency solver, it started alerting us directly to this fact. We

could certainly find a way to hide our heads in the sand and go back

to testing with old pip and pretending we knew what was being tested

there, but the question is whether what we were actually testing

that way was worthwhile enough to try to continue doing it, now that

we have proof it wasn't what we were wanting to test.

The challenge with actually testing what we wanted has always been

that there's many hundreds of packages we depend on and, short of

writing one ourselves, no tool available to find a coherent set of

versions of them which satisfy the collective lower bounds. The way

pip works, it wants to always solve for the newest possible

versions which satisfy an aggregate set of version ranges, and what

we'd want for lower bounds checking is the inverse of that.

--

Jeremy Stanley