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