Open Stack

On Wed, Jan 20, 2021 at 12:14 PM Stephen Finucane <stephenfin at redhat.com> wrote:
>
> 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

Hmm, I agree with this approach. Sounds quite sane.

I have a related question - do you have a tool to recommend that would
check whether all modules used directly by the project are in
requirements.txt already? I.e. that there are no directly-used modules
that are actually pulled in as indirect dependencies?
That would improve the proposed approach as well as general
requirements condition.

-yoctozepto