Open Stack

On 2020-04-18 10:41:16 +0200 (+0200), Radosław Piliszek wrote:
[...]
> Let's ask packagers if they ever used this info. Maybe we are
> doing something just for doing it (and not really *doing* it
> actually). ;-)
[...]

Distro package maintainers asked us to indicate what ranges of
dependencies our projects can work with. Some projects additionally
want to be able to assert that they support older versions of some
of their dependencies when deployed in a stand-alone fashion. It's
been only relatively recently that we switched from enforcing
exactly matching version ranges for dependencies across all
OpenStack projects, to allowing them to indicate that they support
older versions of software than some other projects. This assertion
isn't much use, though, if it's not tested. Providing a
project-specific list of lower constraints allows a project to
verify that its indicated minimum dependency versions are actually
working in some capacity, and at the same time provides a list of
the exact versions of its entire transitive dependency set used in
performing those tests.

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

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

> 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.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200418/9a493cdd/attachment.sig>