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

Attachment: signature.asc
Description: PGP signature

Reply via email to