Skip to content

feat(just): pin the test interpreter and fan out over python versions locally - #297

Open
d-v-b wants to merge 1 commit into
mainfrom
claude/zarr-metadata-test-python-versions-2af473
Open

d-v-b wants to merge 1 commit into
mainfrom
claude/zarr-metadata-test-python-versions-2af473

Conversation

@d-v-b

@d-v-b d-v-b commented Aug 14, 2026 •

Copy link
Copy Markdown
Owner

🤖 AI text below 🤖

Adds an explicit py variable to test recipes in the three packages, wires CI's matrix version into the recipe call, and adds test-all over literal supported-version lists. A selected version uses its own .venv-<version> directory, avoiding replacement of the default project environment when switching interpreters.

Previously the recipe used the environment selected by an earlier uv sync or local setup. A contributor could still reproduce a matrix leg with an explicit uv command; the improvement is making that selection part of the recipe interface. The existing CI version matrices remain unchanged.

Earlier verification reported multi-version zarr-metadata runs and rendered commands for the other packages. This factual pass inspected the recipes and CI wiring; it did not independently rerun every supported Python version. Argument quoting through the nested test-all call remains a documented limitation.

… locally

`just test` took no interpreter, so which python it ran on was ambient state:
whatever the project environment happened to hold. CI got the right answer only
because the preceding `uv sync --python` step had shaped that environment, and
locally there was no way to reproduce a single matrix leg at all.

Add a `py` variable that pins the interpreter in the recipe itself, and a
`test-all` recipe that loops over the supported versions.

A pinned version gets its own environment directory. `uv run --python` does not
merely select an interpreter: when the project environment's interpreter does
not match, uv deletes and rebuilds it. Without this, the advertised
`just py=3.12 test` would destroy the `.venv` the developer was working in and
strand it on the pinned version — and for zarr-indexing, whose recipes run
against the repo-root project, the casualty would be the root zarr environment.
CI is unaffected either way, since its `uv sync --python` has already shaped
the environment to the matrix version.

The version lists stay literal, mirroring the classifiers in pyproject.toml and
the workflow matrices. Deriving them by scraping the classifiers was tried and
dropped: the list feeds only `test-all`, so a bad scrape could not affect what
CI covers, and a regex over TOML can produce a wrong-but-plausible list where a
literal can only be stale.

Assisted-by: ClaudeCode:claude-opus-5

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant