Codecov Report

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

@@            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.

@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.

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

@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.

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 ofsetuptools 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 usingpip-tools that knows how to extract PEP 517 build deps.

Reverting the version pinning in pyproject.toml in#1201