Revert pinning of build-time dependencies

[seifertm]

Pinning to specific versions in pyproject.toml makes it very hard for downstream packagers to build pytest-asyncio from source.

see #1192 (comment)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.81%. Comparing base (b398244) to head (ffb6c5a).

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[webknjaz]

Would you try adding PIP_CONSTRAINT into CI/tox infra?

[seifertm]

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.

[webknjaz]

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.

[seifertm]

The new changes:

• unify the constraints in dependencies/default/constraints.txt and dependencies/docs/constraints.txt. Managing separate constraints for separate extras previously led to issues when both files specify constraints on the same dependency and that dependency is bumped by Dependabot (see for example Build(deps): Bump packaging from 24.1 to 24.2 in /dependencies/docs #986). This step also allows adding constraints on build-time dependencies that would otherwise have to be added to both files
• bump the minimum tox version to v4.28 to use the newly introduced constraints configuration option to pin dependencies during the tox setup. This allows getting rid of the install_command override in favor of deps and constraints.
• configures tox such that it uses pyproject-build to generate the sdist and wheel in the dist/ folder. The wheel is used in subsequent tox environments. This is used as part of the CI pipeline to create the distribution packages for PyPI. The fact that CI uses the new tox "build" environment automatically brings version pinning to the GitHub Actions pipeline and reduces the difference between CI and development environments.
• Pin versions for setuptools, setuptools-scm as well check-wheel-contents and twine which were previously unaccounted for

[seifertm]

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.

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 constraints.txt which is specific to Pip, towards pylock.toml. My understanding is that the idea is to have only a single pylock.toml per project, similar to poetry.lock or uv.lock.

Wouldn't a single constraints.txt be closest to that approach?