Open Stack

On Sat, Apr 18, 2020 at 2:56 PM Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2020-04-18 10:41:16 +0200 (+0200), Radosław Piliszek wrote:
> > it looks like lower constraints tries to be like npm/yarn lockfile
> > in nodejs world [1] [2].
>
> The constraints mechanism in pip was actually added by members of
> the OpenStack community, as a stop-gap until pip could grow an
> intelligent dependency solver. It allows us to pre-compute a known
> compatible set of package versions. I'm not really that familiar
> with the state of art in the Javascript ecosystem, but pip
> constraints lists are not a list of dependencies, they're a list of
> versions the installer should use to override its normal version
> selection for any matching package names in your list of
> dependencies and their transitive dependency chain as well. This
> allows you to keep your declaration of supported direct dependencies
> and their possible ranges of versions separate from the list of
> exact versions you want applied for some particular scenario.
> Because a constraints list is treated as a sieve, it can be shared
> between multiple projects in a particular deployment scenario
> without changing the list of packages which will be installed for
> each (merely which versions of them are installed).

Sure, the upper-constraints are doing that just fine globally.
The issue is lower-constraints are not really trustworthy.

> > On the other, that it is to ensure our lower constraints are
> > modern enough to handle our code. But it seemingly falls short
> > doing either, because the first is not enforced,
>
> In what way is it not enforced? Or put another way, what were you
> expecting it to enforce which it doesn't?

Oh, I mean the lockfile part.
If lower-constraints jobs pass without enforcing each transitive
dependency, then it's not enforced in this way.

> > and the second is additionally limited in that we only run
> > unit testing (as far as I could see) where real deps testing will
> > actually happen in functional testing (as in unit testing a ton of
> > functionality is mocked anyway, so we may often end up testing
> > importability at most).
> [...]
>
> There is nothing stopping folks from applying constraints lists in
> whatever Python-based jobs they want.

Indeed, I'm just pointing it out.

-yoctozepto