Repository navigation
Drop upper bound for pytest from the core packaging metadata #1605
Description
It's usually problematic for many reasons to have it and is recommended to only have a lower bound set. PyPA's discouraged such a practice for a long time.
Today it broke pytest's CI, for example, as it runs checks against own plugins ecosystem on main which is future-versioned:
- https://github.com/pytest-dev/pytest/actions/runs/41187918874/job/124498606803?pr=15309#step:6:36
- build(deps): Bump the github-actions group with 3 updates pytest#15309 (comment)
- [automated] Update plugin list pytest#15311 (comment)
- https://github.com/pytest-dev/pytest/blob/0212785e34eb635b3359e4eccc757de95bf39036/tox.ini#L190 <-- the metadata integrity check itself
As of now, this fully blocks any pytestPRs from being merged.
Activity
build: drop pytest upper bound (pytest-dev#1605)
tjkuson commentedon Nov 1, 2026
Thank you for the report and sorry about the issue. It looks like the upper bound was introduced a long time ago when there was an actual incompatibility with a pytest release and was never removed.
tjkuson commentedon Nov 1, 2026
The upper bound has been removed on main and that change should be included in the next release.
build: drop pytest upper bound (pytest-dev#1605) (pytest-dev#1606)
seifertm commentedon Nov 1, 2026
Exactly! If I remember correctly, the situation back then was that pytest-asyncio wasn't prepared for a breaking change in pytest. This broke users' tests and resulted in a lot of bug reports (or votes in bug reports).
I was aware that upper version bounds are discouraged for build dependencies. I wasn't aware that it's the same for runtime dependencies. Does PyPA suggest any alternative to upper version bounds for declaring compatibility with upstream dependencies?
webknjaz commentedon Nov 2, 2026
@seifertm it's basically up to the end users to deal with their envs. Pip has constraint files that can help dealing with this quite cleanly, for example. You just have to make sure you don't interfere with the users' ability to take responsibility for their env.
One effect/behavior people often don't realize is that many depresolvers would enter their backtracking mode upon hitting this. And the consequence is that the installer will go for an older version of your distribution that might have had more relaxed dependency bounds. This may also mean that it could attempt trying out every historic version all the way back to the first release and find something that would end up not conflicting on the metadata level but will blow up way later when used.
I think that instead of setting an upper bound (meaning that the dist is never intended to be compatible with the dependency), there should be a way to indicate that it was compatible with a certain version.
Currently, you can just say so in the docs that you've tested it with a certain version and it didn't crash. Maybe, you could test against a range of pytest versions and single-source that through a Sphinx extension.
We currently don't have a standard for including a file that could say "here's the deps this dist was tested with and it worked at the time".
But a few years ago @CarliJoy brought up an idea of sticking a true lock file into wheels: https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies/99497. And it was discussed with a few people, including at the last Packaging Summit at EuroPython 2026 in Kraków: https://hackmd.io/@jezdez/europython2026-packaging-summit?stext=21415%3A113%3A0%3A1793611915%3ADHGBuT.
It's not a standard (yet?) but I've been hoping the lockfile inclusion would close this specific need of trying to guess what were the transitive deps versions of a given project at the time of release in their test env.