Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.maint.python > #17483
| From | Jeremy Stanley <fungi@yuggoth.org> |
|---|---|
| Newsgroups | linux.debian.maint.python |
| Subject | Re: Upstream dependency version requirements [Was: Re: review for beets/2.9.0-1] |
| Date | 2026-05-04 15:40 +0200 |
| Message-ID | <MR1GF-2xxE-13@gated-at.bofh.it> (permalink) |
| References | <MQHeV-2joj-3@gated-at.bofh.it> <MR0rf-2wJt-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
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
Back to linux.debian.maint.python | Previous | Next — Previous in thread | Next in thread | Find similar
review for beets/2.9.0-1 Jeroen Ploemen <jcfp@debian.org> - 2026-05-03 17:50 +0200
Upstream dependency version requirements [Was: Re: review for beets/2.9.0-1] Peter Pentchev <roam@ringlet.net> - 2026-05-04 14:20 +0200
Re: Upstream dependency version requirements [Was: Re: review for beets/2.9.0-1] Jeremy Stanley <fungi@yuggoth.org> - 2026-05-04 15:40 +0200
Re: Upstream dependency version requirements [Was: Re: review for beets/2.9.0-1] Peter Pentchev <roam@ringlet.net> - 2026-05-05 11:50 +0200
Re: Upstream dependency version requirements [Was: Re: review for beets/2.9.0-1] "Pieter Lenaerts" <plenae@disroot.org> - 2026-05-06 08:40 +0200
csiph-web