Open Stack

> 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.

+1

>
> 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.

As someone that has spent some time working on l-c jobs/issues, I kind
of have to agree with this.

For historical reference, here's the initial proposal for performing
lower constraint testing:

http://lists.openstack.org/pipermail/openstack-dev/2018-March/128352.html

I wasn't part of most of the requirements team discussions around the
need for this, but my understanding was it was to provide a set range of
package versions that are expected to work. So anyone packaging
OpenStack projects downstream would have an easy way to filter out
options to figure out what versions they can include that will minimize
conflicts between all the various packages included in a distro.

I'm not a downstream packager, so I don't have any direct experience to
go on here, but my assumption is that the value of providing this is
pretty low. I don't think the time the community has put in to trying to
maintain (or not maintain) their lower-constraints.txt files and making
sure the jobs are configured properly to apply those constraints has
been worth the effort for the value anyone downstream might get out of them.

My vote would be to get rid of these jobs. Distros will need to perform
testing of the versions they ultimately package together anyway, so I
don't think it is worth the community's time to repeatedly struggle with
keeping these things updated.

I do think one useful bit can be when we're tracking our own direct
dependencies. One thing that comes to mind from the recent past is we've
had cases where something new has been added to something like
oslo.config. Lower constraints updates were a good way to make it
explicit that we needed at least the newer version of that lib so that
we could safely assume the expected functionality would be present.
There is some value to that. So if we keep lower-constraints, maybe we
just limit it to those specific instances where we have things like that
and not try to constrain the entire world.

Sean