- Notifications
You must be signed in to change notification settings - Fork 164
Revert pinning of build-time dependencies #1201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert pinning of build-time dependencies #1201
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@ ## main #1201 +/- ## ======================================= Coverage 90.81% 90.81% ======================================= Files 2 2 Lines 403 403 Branches 43 43 ======================================= Hits 366 366 Misses 29 29 Partials 8 8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you try adding PIP_CONSTRAINT
into CI/tox infra?
Certainly! I originally intended this to go into a separate PR, but I might as well include it here. |
e24b598
to a8d3b70
Compare I wouldn't recommend having the same constraint file for different envs. Sooner or later you're doomed to run into conflicts, like being unable to update Sphinx because pytest conflicts with setuptools. This is an imaginary scenario but it shows how parts of deptrees in one env might influence dep resolution in other envs. Even if they are physically separate, you're making them tightly coupled with this. |
The new changes:
|
It's true that with a single constraint file we could miss packages upgrades or have to wait longer for them. On the other hand, it would address issues with automated dependency updates like the one mentioned in my previous comment, tough. In future, I think it's desirable to move away from Wouldn't a single constraints.txt be closest to that approach? |
…ownstream packaging. see pytest-dev#1192 (comment)
Pytest-asyncio currently uses separate constraints files for the base package and the [docs] extra. This creates issues when both files specify constraints on the same dependency and that dependency is bumped by Dependabot in only one file. In that case, the build may fail due to conflicting constraints (see for example pytest-dev#986). This patch creates a unified constraints file for pytest-asyncio. There's still a second constraints file for pytest-min, which is used to test against the minimum supported version of pytest.
…than assembling a custom install_command.
This avoids building the package separately for each environment.
…d tox environment. This simplifies the GitHub Actions workflow, allows future pinning of the dependencies associated with the check, and aligns development and CI setups more closely.
a8d3b70
to ffb6c5a
Compare
I'd argue it might induce some.
Not really. There's If you read the last paragraph of the section you linked, you'll see that it calls out the multi- vs. single-use lock files. You can also lurk in https://peps.python.org/pep-0751/#how-to-teach-this to see some more dimmensions of this. Having a combined deptree dump is challenging in trees with native modules in the deps because said deps aren't always static and can't always be computed accurately (or at all) on a single platform for other platforms. |
FWIW, just because there's a standard format for storing resolutions, it doesn't mean that the underlying limitations magically disappeared: jazzband/pip-tools#826. |
Another bit of info that's lost with this patch is which deps are direct vs. transitive. |
Pinning to specific versions in pyproject.toml makes it very hard for downstream packagers to build pytest-asyncio from source.
see #1192 (comment)