Skip to content

v1.108.308 — Ownership and freshness are different properties

Choose a tag to compare

@jgravelle jgravelle released this 29 Aug 17:20
· 33 commits to main since this release

No user-facing fix. This release is about a question worth asking out loud: were we eating stale dog food?

We develop jcodemunch using jcodemunch. This box ran 1.108.293 against a 1.108.307 tree — fourteen releases, six days.

Why nothing caught it

The release checklist has eight steps: bump, test, lint, CI-env, push, build/upload, tag/release, registry. None of them touch the dev box. The process is complete with respect to users and silent with respect to us. The package was installed as a regular (copied) distribution, so edits to the tree never reached the running server; only an explicit reinstall would have, and that didn't happen for fourteen releases.

verify_package_integrity() cannot see this and is not meant to. It runs on every CLI invocation and inspects the distribution — but it asks "is this the official distribution?", a supply-chain question. It would certify a fourteen-release-old official install without complaint. Ownership and freshness are different properties, and having a startup check that looks at the distribution made it feel covered.

The part that wasn't the version gap

With the dogfood that stale, every fix that week was verified with PYTHONPATH=src rather than through the server. The verification path routed around the product, and nobody decided that. Each individual choice was correct; the pattern was the finding.

To be precise about what was and wasn't affected: tests run from source, CI runs from source, and published artifacts are built from the tree — users were never at risk. What went stale was our own consumption of our own tool.

What changed

install-status now reports a source_drift block comparing the running __version__ against the tree's pyproject.toml.

Tri-state, and drifted: None means COULD NOT ESTABLISH — never False. Reporting "not drifted" for a comparison that was never made is precisely the defect this project keeps finding in its own instruments: 1.108.305's churn axis on a shallow clone, 1.108.306's test axis after truncation, a dead-code refusal published as 0.0. It reads UNKNOWN under PYTHONPATH=src, which is how the suite and CI both run, and the tests pin that case: 4 of 10 fail when UNKNOWN is collapsed to False.

Maintenance Practice 11 records the process half — a release does not end at the registry.

Related

All five suite packages are editable installs now, so tree-vs-install drift is no longer possible; only the restart remains, because a running server keeps serving what it loaded at startup.

scripts/repair-munch-installs.ps1 repairs an interpreter and refuses while any server is running — on Windows, pip uninstall of a package whose console script is live removes the .pth and dist-info first, then dies on the locked .exe, leaving it unimportable with a ~ staging turd behind. That refusal is the most valuable line in the file. It is excluded from the sdist: it hard-codes this box's paths and cannot work on yours.


pip install --upgrade jcodemunch-mcp