On Wed, 2021-01-20 at 07:26 +0000, Lucian Petrut wrote:
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
Yes, I've looked into doing this elsewhere (as promised) and it seems to do the job quite nicely. It's not perfect but it does seem to be "good enough" and captures basic things like "I depend on this function found in oslo.foo vX.Y and forgot to bump my minimum version to reflect this". I think these jobs probably offer _more_ value now than they did in the past, given pip is now finally honouring the explicit constraints we express in these files, so I would be in favour of this approach rather than dropping l-c entirely. I do realize that there is some degree of effort here in getting e.g. all the oslo projects fixed, but I'm happy to help out with and have already fixed quite a few projects. I also wouldn't be opposed to dropping l-c on *stable* branches so long as we maintained for master, on the basis that they were already broken so nothing is really changing. Sticking to older, admittedly broken versions of pip for stable branches is another option and might help us avoid a deluge of "remove/fix l-c" patches for stable branches, but I don't know how practical that is? Stephen
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
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: [...] 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