Conversation
uv does not lock [build-system].requires or its transitives (astral-sh/uv#5190), so every fresh sync resolves hatchling, uv-dynamic-versioning, setuptools and their deps at floating-latest with no hash check. Pinning them via [tool.uv].build-constraint-dependencies makes the build environment reproducible across machines and CI runs. Versions chosen are the current latest of each. setuptools is included for the legacy build of the strict-no-cover git dep.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — additive build-env constraints, strictly improves reproducibility; the inline note about wheel/tomli is a non-blocking nit.
Extended reasoning...
Overview
This PR adds a [tool.uv].build-constraint-dependencies list to pyproject.toml pinning 11 packages (hatchling, uv-dynamic-versioning, their transitives, and setuptools) that uv otherwise resolves at floating-latest inside PEP 517 build-isolation environments. The uv.lock change is the auto-generated [manifest].build-constraints mirror of the same list. No source code, runtime dependencies, or test configuration is touched.
Security risks
None. Build constraints only narrow which versions uv may select for already-required build backends; they cannot introduce new packages into the resolution. All pinned packages are well-known PyPI projects already implicitly fetched today. If anything, pinning reduces supply-chain exposure by removing the floating-latest fetch.
Level of scrutiny
Low. This is a purely additive tooling/config change with a clear, well-documented rationale (astral-sh/uv#5190). The worst plausible failure mode — a stale pin breaking uv sync after a future toolchain bump — would surface immediately and loudly in CI, and is trivially fixed by bumping the pin. The change is self-contained to two files and has no effect on the published wheel or runtime behavior.
Other factors
- The one finding (missing
wheelpin forexamples/snippetsandtomlifor the py3.10 lane) is a minor coverage gap, not a regression: those two packages float today and will continue to float, while 11 others stop floating. The PR remains a strict improvement. - No CODEOWNERS file in the repo; no prior reviewer comments or outstanding discussion on the PR.
- Author verified locally with
uv sync --frozen --reinstall-package mcp -vanduv lock --check.
1 participant
uvdoes not lock[build-system].requiresor its transitives (astral-sh/uv#5190). On every freshuv sync, the build-isolation step for the workspace packages resolveshatchling,uv-dynamic-versioning, and ~8 transitives at floating-latest with no hash check. Thestrict-no-covergit dep additionally pulls latestsetuptoolsvia the legacy fallback.This pins those packages via
[tool.uv].build-constraint-dependenciesso the build environment is reproducible across machines and CI. uv records the constraints inuv.lock's[manifest]section but does not add them to the resolution graph.Motivation and Context
Reproducible builds — without this, two fresh syncs on different days can use different build-backend versions.
How Has This Been Tested?
uv sync --frozen --reinstall-package mcp -vshows the build-isolation resolver now selecting the pinned versions.uv lock --checkis a no-op.Breaking Changes
None.
Types of changes
Checklist
Additional context
If/when
strict-no-covermoves from a git dep to a PyPI release, thesetuptoolspin can be dropped.