Re: Upstream dependency version requirements [Was: Re: review for beets/2.9.0-1]

Jeremy Stanley <[email protected]> Mon, 4 May 2026 12:58:02 +0000
Newsgroups	gmane.linux.debian.devel.python
Message-ID	<[email protected]>
On 2026-05-04 15:07:22 +0300 (+0300), Peter Pentchev wrote:
>On Sun, May 03, 2026 at 03:49:21PM -0000, Jeroen Ploemen wrote:
[...]
>> For both of the above, it's often an open question whether version 
>> restrictions declared by upstream are actually hard requirements or 
>> just a matter of "we prefer to have everyone use the version we 
>> tested with".
>
>From my experience with various upstream projects, both individual 
>authors with varying levels of experience and workflows, and 
>more complex organizations (e.g. OpenStack), IMHO it is most useful to, 
>at least initially, "assume good faith"
[...]

To use the OpenStack example, our dependency management upstream has 
both parts Jeroen mentioned: 1. requirements.txt files (or similar 
lists in pyproject.toml) for each individual project are coordinated 
so that they remain coinstallable while staying as loosely-defined 
as possible; 2. a global constraints list essentially "pins" a 
solution for requirements across all OpenStack projects like a 
lockfile, in order to stabilize upstream integration testing and 
allow us to quickly identify regressions in dependencies as new 
releases for them appear.

It's always been our goal to remain flexible for the benefit of 
downstream distribution package maintainers, and when individual 
projects within OpenStack specify a lower bound, upper bound, or 
excluded version in their requirements it typically signals an 
actual regression that project is trying to avoid (either because 
the project has started depending on a new feature from that 
dependency, or the dependency introduced a backward incompatibility 
or presumed-temporary breaking bug).

Put another way, the constraints list is the exact versions of 
dependencies (including transitive dependencies) that were tested 
with upstream at that time, but we understand that distributions 
downstream have a need to make our software work with different 
versions than what we've tested and so expect them to do their own 
testing where relevant in order to confirm everything continues to 
work as intended.

I won't speculate about the Beets upstream dependency management, 
but as a user of it myself (and having managed pip-installed venvs 
of it myself in the past for various reasons), it does appear they 
have a very complex set of requirements so almost certainly are 
working around the sorts of problems which arise from that.
-- 
Jeremy Stanley
signature.asc (application/pgp-signature, 963 B)