Summary
pyproject.toml sets:
[tool.hatch.envs.defaults]
installer = "uv"
Hatch's inherited base environment is default (singular). As written, defaults (plural) is just a standalone environment — it shows as its own row in hatch env show and nothing references it as a template — so installer = "uv" is never inherited by test, docs, doctest, etc. Those environments silently use hatch's default virtualenv/pip backend, and the uv installer the project appears to intend has never actually been active.
Impact
Mostly latent today (since uv was never enabled), but:
-
Contributors whose Python is uv-managed (uv python install, exposed via the ~/.local/bin/pythonX.Y symlink) can hit a hard env-creation failure, because the virtualenv backend mis-relocates the python-build-standalone interpreter:
sys.base_prefix = '/install'
ModuleNotFoundError: No module named 'encodings'
Proposed fix
Rename [tool.hatch.envs.defaults] → [tool.hatch.envs.default] so the uv installer is inherited by all environments.
Activating the uv installer for the first time also surfaces two CI requirements (handled in the linked PR):
- uv must be available to the hatch-based workflows (
test/gputest/hypothesis) — they install hatch via the pypa/hatch action and never set up uv, so hatch tried to bootstrap it and failed. Fixed with astral-sh/setup-uv + HATCH_ENV_TYPE_VIRTUAL_UV_PATH=uv.
- macOS: hatch's pyapp (standalone) build ships a
pip whose shebang points at a non-existent python3.12; with the uv installer active hatch invokes it and fails (exit 126). Fixed by installing hatch via pip install hatch==1.16.5 in test.yml.
Note: .python-version (added in #3972 for the dev env) is not involved — the failing binary was hatch's runtime pip, not the environment interpreter.
Verification
hatch env show lists defaults as its own standalone environment. Renaming to default flips the test matrix env from the virtualenv backend (pyvenv.cfg → virtualenv = ...) to uv (pyvenv.cfg → uv = ...), and with the CI changes the full matrix (macOS / Ubuntu / Windows × py3.12/3.13/3.14 × optional/minimal) passes.
Summary
pyproject.tomlsets:Hatch's inherited base environment is
default(singular). As written,defaults(plural) is just a standalone environment — it shows as its own row inhatch env showand nothing references it as a template — soinstaller = "uv"is never inherited bytest,docs,doctest, etc. Those environments silently use hatch's defaultvirtualenv/pip backend, and the uv installer the project appears to intend has never actually been active.Impact
Mostly latent today (since uv was never enabled), but:
Contributors whose Python is uv-managed (
uv python install, exposed via the~/.local/bin/pythonX.Ysymlink) can hit a hard env-creation failure, because thevirtualenvbackend mis-relocates the python-build-standalone interpreter:Proposed fix
Rename
[tool.hatch.envs.defaults]→[tool.hatch.envs.default]so the uv installer is inherited by all environments.Activating the uv installer for the first time also surfaces two CI requirements (handled in the linked PR):
test/gputest/hypothesis) — they install hatch via thepypa/hatchaction and never set up uv, so hatch tried to bootstrap it and failed. Fixed withastral-sh/setup-uv+HATCH_ENV_TYPE_VIRTUAL_UV_PATH=uv.pipwhose shebang points at a non-existentpython3.12; with the uv installer active hatch invokes it and fails (exit 126). Fixed by installing hatch viapip install hatch==1.16.5intest.yml.Note:
.python-version(added in #3972 for the dev env) is not involved — the failing binary was hatch's runtime pip, not the environment interpreter.Verification
hatch env showlistsdefaultsas its own standalone environment. Renaming todefaultflips thetestmatrix env from the virtualenv backend (pyvenv.cfg→virtualenv = ...) to uv (pyvenv.cfg→uv = ...), and with the CI changes the full matrix (macOS / Ubuntu / Windows × py3.12/3.13/3.14 × optional/minimal) passes.