Open Stack

On 2020-12-11 10:20:35 +0100 (+0100), Bernard Cafarelli wrote:
> now that master branches have recovered from pip new resolver use,
> I started looking at stable branches status. tl;dr for those with
> open pending backports, all branches are broken at the moment so
> please do not recheck.

Was there significant breakage on master branches (aside from
lower-constraints jobs, which I've always argued are inherently
broken for this very reason)? If so, it didn't come to my attention.
Matthew did some fairly extensive testing with the new algorithm
across our coordinated dependency set well in advance of the pip
release to actually turn it on by default.

> Thinking about fixing gates for these branches, older EM branches
> may be fine once the bandit 1.6.3 issue [1] is sorted out, but
> most need a fix against the new pip resolver.
> 
> pip has a flag to switch back to old resolver, but this is a
> temporary one that will only be there for a few weeks [2]
> 
> From a quick IRC chat, the general guidance for us was always to
> leave pip uncapped, and the new resolver issues are actually
> broken requirements.
[...]

Yes, it bears repeating that anywhere the new dep solver is breaking
represents a situation where we were previously testing/building
things with a different version of some package than we meant to.
This is exposing latent bugs in our declared dependencies within
those branches. If we decide to use "older" pip, that's basically
admitting we don't care because it's easier to ignore those problems
than actually fix them (which, yes, might turn out to be effectively
impossible). I'm not trying to be harsh, it's certainly a valid
approach, but let's be clear that this is the compromise we're
making in that case.

My proposal: actually come to terms with the reality that
lower-constraints jobs are a fundamentally broken concept, unless
someone does the hard work to implement an inverse version sort in
pip itself. If pretty much all the struggle is with those jobs, then
dropping them can't hurt because they failed at testing exactly the
thing they were created for in the first place.
-- 
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/20201211/131c7e6b/attachment.sig>