Rework setuptools-scm configuration

[seifertm]

pytest-asyncio has an unnecessarily complex setuptools-scm configuration, which is split over multiple files (pyproject.toml and setup.cfg). This setup broke with the recent release of setuptools-scm v9.2 leading to build errors.

This PR addresses several issues:

• it provides pytest_asyncio.__version__ through importlib.metadata as opposed to a version file leading to simpler configuration
• it bumps setuptools-scm to v9.2.0
• it pins the versions build dependencies (setuptools and setuptools-scm) to make builds reproducible. Build dependencies should be updated by dependabot nowadays

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.91%. Comparing base (4fbe1e0) to head (d28f82e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1192      +/-   ##
==========================================
+ Coverage   88.88%   88.91%   +0.02%     
==========================================
  Files           2        2              
  Lines         405      406       +1     
  Branches       44       44              
==========================================
+ Hits          360      361       +1     
  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]

@seifertm FYI this way of packaging with pinning the build deps is actively harmful for downstreams like Linux distribution packagers. Instead, use pip constraints to make the upstream packaging predictable.

[webknjaz]

We were just talking about it the other day over at PyPUG, by the way: pypa/packaging.python.org#1886

[seifertm]

@seifertm FYI this way of packaging with pinning the build deps is actively harmful for downstreams like Linux distribution packagers. Instead, use pip constraints to make the upstream packaging predictable.

@webknjaz Thanks for bringing this up, I didn't think of this.

My understanding is that downstream packagers may want to build from source using the build dependencies that are available in their respective package repositories. Specifying exact versions of build dependencies would interfere with that. Is that about right?

In that case, let's revert to specifying lower (and upper?) bounds for build dependencies and pin the version using a different mechanism, as you suggested.

[webknjaz]

My understanding is that downstream packagers may want to build from source using the build dependencies that are available in their respective package repositories. Specifying exact versions of build dependencies would interfere with that. Is that about right?

@seifertm yes. Downstreams usually don't have per-venv separation and so there's exactly one version of a build deps on the system at a time. For example, one version of setuptools installed globally. This causes conflicts and would cause headache as they'll be trying to patch out the limitations.

In that case, let's revert to specifying lower (and upper?) bounds for build dependencies and pin the version using a different mechanism, as you suggested.

I usually recommend the lower bound corresponding to a version where a feature you use was added. Upper bounds cause almost as many problems as hard pins. Version exclusions (!=) are fine. Though, some build backends (uv, flit core) still advertise upper bounds, which isn't friendly with downstreams nevertheless.

Though, while the metadata shouldn't be overly tight, you can still set the $PIP_CONSTRAINT env var where you call pypa/build or pip (in CI/tox/nox/etc). Point it to a file with all the transitive deps pinned. You can generate/manage this file using pip-tools that knows how to extract PEP 517 build deps.