build: ground sub-package packaging in current uv/hatch/setuptools-scm guidance

[d-v-b]

🤖 AI text below 🤖

Stacked on #361: the base is that branch, so this diff shows only these changes. Merge #361 first.

Summary

I checked our monorepo packaging against the current docs for uv (0.12.18), Hatch (1.18.1) / hatchling (1.32.4), setuptools-scm (10.3.4), hatch-vcs (0.5.0), and the PyPA sdist spec. This PR fixes the three gaps that were worth fixing.

1. Test each sdist on its own before release (ci:)

hatch build builds the wheel from the source tree, so nothing ever used the sdist. The first version of zarr-developers#4229 produced sdists that pip refuses to unpack (a symlink pointing outside the archive), and the release workflows would have uploaded them. Each release workflow's test_artifacts job now:

• builds a wheel from the sdist with pip (pip wheel), which unpacks under the sdist format rules: no links out of the archive;
• runs just test and just docs-check from the unpacked sdist, with no repo checkout.

The job has no checkout, so zarr-http-server resolves zarr from PyPI there. That also covers the zarr>=3.1 floor, which repo runs never check: uv run --with-editable versions are "respected regardless of the project's requirements".

2. Replace deprecated git_describe_command (build:)

setuptools-scm deprecates git_describe_command in favour of scm.git.describe_command. The DeprecationWarning is swallowed during builds. This moves the root and all three sub-packages to the new key and adds setuptools-scm>=9 to build-system.requires. hatch-vcs passes raw-options to setuptools_scm.get_version(), which only accepts scm from 9.0; 8.4, the version the docs name, was never released.

• tag.prefix is setuptools-scm's documented option for monorepos, but hatch-vcs 0.5.0 can't reach it (get_version() takes no tag argument).
• The remaining tag_regex deprecation warning comes from hatch-vcs's own translation of tag-pattern, so we can't fix it from our config.
• ⚠ Anyone building zarr from source now needs setuptools-scm>=9; e.g. the conda-forge recipe's host requirements.

3. Commit zarr-metadata's uv.lock

.gitignore excluded it ("a library, not an app"). uv's docs say uv.lock "should be checked into version control", with no exception for libraries, and the other two sub-packages already commit theirs.

Checked, no change needed

• Separate projects, not a uv workspace: uv says workspaces "are not suited for cases in which members have conflicting requirements, or desire a separate virtual environment for each member". A workspace also forces one requires-python (ours differ: 3.11 vs 3.12), and each package releases independently.
• No tool.uv.sources (chore: keep sub-package pyproject.toml standalone; overlay in-repo zarr from just #361): matches uv's publishing advice to verify with --no-sources.
• Hatch 1.18 environment sources / Hatch workspaces: could replace the justfile overlay, but the sub-packages run on uv + just, not Hatch envs, so switching gains nothing.

Verification

Check	Result
hatch version for root / zarr-metadata / zarr-indexing / zarr-http-server, before vs after	identical (3.4.1.dev28+g5d4092a2b, 0.5.1.dev80, 0.2.2.dev91, 0.1.1.dev95), each +1 commit after committing
setuptools-scm 8.2.0 / 8.3.1 with scm=	TypeError, hence >=9
new pip step on the old broken zarr-developers#4229 sdist	fails: "would link to … outside the destination"
new pip step on sdists from this branch (hatch 1.16.5, as in CI)	all three build
just test from unpacked sdists	metadata 595 passed; indexing 1547 passed / 207 skipped (no zarr); http-server 212 passed / 9 skipped
just docs-check from unpacked sdists	all three build under --strict
zizmor, GitHub workflow schema	clean

I haven't run the release workflows: on the fork, workflow_dispatch would also trigger the TestPyPI upload job.

Once zarr-developers#4229 lands, zarr-metadata's new uv.lock needs a uv lock for zarr-developers#4229's aligned docs pins.

🤖 Generated with Claude Code

[d-v-b]

🤖 AI text below 🤖

Superseded by zarr-developers#4407.