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 88.91%. Comparing base (5900a4d) to head (a8d3b70).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1201   +/-   ##
=======================================
  Coverage   88.91%   88.91%           
=======================================
  Files           2        2           
  Lines         406      406           
  Branches       44       44           
=======================================
  Hits          361      361           
  Misses         35       35           
  Partials       10       10           

☔ 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?

[webknjaz]

Nit: it's usually nice to make the specs sparse.

Suggested change

	"setuptools>=77",
	"setuptools-scm[toml]>=6.2",
	"setuptools >= 77",
	"setuptools-scm [toml] >= 6.2",

And it's be a good idea to specify in a code comment which features of the deps require those minimum versions to keep track of why they are set and help judge if it's okay to bump them in the future.

[seifertm]

I haven't traced how the minimum versions got in place, but I understand the idea. We should add a comment when bumping the minimum versions in the future.

[seifertm]

I just noticed that I applied your changes and it immediately got reformatted to the old status by pre-commit CI running pyproject-fmt.

[seifertm]

Pyproject-fmt doesn't seem to have a configuration option to change the formatting of dependencies, so I suggest we just go with that. Or do you feel strongly about the spaces?

[webknjaz]

I think they improve readability and so I use this style in PyPUG. Many "opinionated" tools promote weird opinions so I avoid them. For human-readable content, it's important, for generated things (like pip-tools output) less so.

[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?