Skip to content

feat: track pyproject.toml and uv.lock - #23

Merged
okcodes merged 3 commits into
mainfrom
python-projects
Sep 10, 2026
Merged

okcodes merged 3 commits into
mainfrom
python-projects

Conversation

@okcodes

@okcodes okcodes commented Sep 10, 2026

Copy link
Copy Markdown
Collaborator

Settles the Python projects backlog entry the way it asked to be settled —
by measurement, not discussion.

The experiment the entry specified

put a project in sandbox/py/, bump the version by hand, run uv lock, and
diff. If the only change is the project's own version, the lock is trackable
on exactly the terms Cargo.lock and package-lock.json are.

Exactly one line changed, and uv lock afterwards produced a byte-identical
file. So the entry is computable with no network and no knowledge of the
dependency graph, which is the standard the other locks are held to.

A uv workspace turned out to be the Cargo shape rather than the npm one —
one entry per member in a shared lock, keyed by the name each manifest declares.
That is the pairing vump already implements, so workspaces needed nothing new.

What differs from Cargo

One thing: Cargo records a source for what it fetched and none for what it
built; uv records one for both and marks the local ones editable. The shared
[[package]] machinery now takes that as a predicate.

That distinction is load-bearing, not cosmetic — a published release of a
workspace member appears in the lock under the member's own name, so the name
filter alone cannot tell them apart. My first test for this passed with the
predicate deliberately broken; the one that replaced it fails properly.

A version named in dynamic is refused: PEP 621 means a build backend computes
it, and the lock omits the version line entirely in that case.

Sandbox

sandbox/py/single-project, verified against real uv:

$ vump minor --allow-nested
OK   1.0.0 -> 1.1.0
  pyproject.toml
  uv.lock

$ uv run python -m demo
demo 1.1.0

The demo reads its version from installed metadata rather than repeating it in
source, so the sandbox does not quietly demonstrate a second place a version can
go stale. Covered by both sandbox guard tests.

Also here

Detection and the refusal that lists the alternatives were two hand-written
sets that had already drifted once — and the test guarding them was a third
hand-written set with the same weakness. All three collapse onto one list, and
the message is generated from it.

The Declarative version-file formats entry named pyproject.toml and
*.csproj as its motivation. Both are now built in, neither costing more than
a day, which is evidence against that entry rather than for it — recorded
there.

🤖 Generated with Claude Code

okcodes and others added 3 commits September 9, 2026 21:18
`[project].version` is the same in-place TOML edit vump already performs for
Cargo. What was undecided was the lock, and it is settled the way npm and Cargo
were — by measurement. Editing only the project's own entry in a uv.lock and
asking uv to re-lock produced a byte-identical file, so the entry is computable
with no network and no knowledge of the dependency graph, which is the standard
Cargo.lock and package-lock.json are held to.

A uv workspace is the Cargo shape rather than the npm one: one entry per member
in a shared lock, keyed by the name each manifest declares. That is the pairing
vump already implements, so members need nothing new.

The two TOML locks differ in one thing — Cargo records a source for what it
fetched and none for what it built, uv records one for both and marks the local
ones editable — so the shared machinery takes that as a predicate. A published
release of a workspace member appears under the same name as the member, and
only the source tells them apart.

A version named in `dynamic` is refused: PEP 621 means a build backend computes
it, so nothing here is vump's to move.

Also collapses detection and the refusal that lists the alternatives onto one
list. They were two hand-written sets that had already drifted once, and the
test guarding them was a third.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sandbox/py/single-project is a manifest and a lock moving together, the shape
the entry existed to test. Verified against real uv rather than asserted: a
bump writes both files, `uv lock` afterwards produces a byte-identical one, and
`uv run python -m demo` reports the new version.

The demo reads its version from installed metadata rather than repeating it in
source, so the sandbox does not quietly demonstrate a second place a version
can go stale.

uv leaves a .venv and __pycache__ behind, which join the sandbox build output
already ignored.

The declarative-formats entry named pyproject.toml and .csproj as the formats
motivating it. Both are now built in, neither costing more than a day, which is
evidence against the entry rather than for it — recorded there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@okcodes
okcodes merged commit 1f43b69 into main Sep 10, 2026
15 checks passed
@okcodes
okcodes deleted the python-projects branch September 10, 2026 05:54
@okcodes
okcodes deployed to Production-Signing September 10, 2026 05:57 — with GitHub Actions Active

This branch was successfully deployed

1 active deployment
Production-Signing — 13d47217 Deployed Sep 10, 2026 by okcodes via Sign, Notarize & Release #37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant