You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: use hatch's default env so the uv installer is inherited (#4023)
* fix: use hatch's `default` env so the uv installer is inherited
`[tool.hatch.envs.defaults]` (plural) is a standalone environment that
nothing inherits from — hatch's base environment is `default` (singular).
As written, `installer = "uv"` never applied to `test`, `docs`, etc., so
those envs fell back to the `virtualenv` backend.
This breaks contributors whose Python is uv-managed: hatch hands the
`~/.local/bin/pythonX.Y` symlink to virtualenv, which mis-relocates the
python-build-standalone interpreter (`sys.base_prefix = '/install'`,
`ModuleNotFoundError: No module named 'encodings'`). Creating the env with
`uv venv` relocates it correctly.
Renaming to `default` makes the intended uv installer apply to all envs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* ci: install uv in hatch-based workflows so the uv installer works
Activating `installer = "uv"` (via the `default` env fix) means hatch now
needs a uv binary to create/sync the test, gputest and hypothesis envs.
These workflows install hatch via the `pypa/hatch` action (a pyapp build
with its own bundled Python) but never set up uv, so hatch fell back to
provisioning uv through its pyapp runtime — whose `pip` has a `python3.12`
shebang that doesn't exist on non-3.12 runners:
.../pyapp/hatch/.../python/bin/python3.12: No such file or directory
Process completed with exit code 126
Add the repo's standard `astral-sh/setup-uv` step (already used by docs/lint
workflows) before "Install Hatch" so hatch finds uv on PATH and uses it
directly. With uv available, `uv venv --python <matrix>` selects the correct
interpreter, so the root `.python-version` (3.12, for the dev env) no longer
interferes with the 3.13/3.14 matrix envs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* ci: point hatch at the setup-uv binary to skip its broken uv bootstrap
Installing uv on PATH is not enough: hatch only skips provisioning its
internal `hatch-uv` env when an explicit uv path is set. Otherwise it
bootstraps uv via its bundled pyapp `pip` (shebang `python3.12`), which
fails on non-3.12 runners with exit code 126.
Set `HATCH_ENV_TYPE_VIRTUAL_UV_PATH=uv` so hatch uses the uv provided by
astral-sh/setup-uv directly instead of bootstrapping. Verified locally:
with the explicit path set, `hatch env create` succeeds.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* ci(test): install hatch via pip instead of the pyapp action
The macOS jobs failed even with uv on PATH: hatch's pyapp (standalone)
build on macOS has a `pip` whose shebang points at a non-existent
`python3.12`, and activating the uv installer makes hatch invoke it
(`exit code 126`). Linux pyapp builds are unaffected, which is why the
GPU and Hypothesis (Linux) workflows pass.
Install hatch with `python -m pip install hatch==1.16.5` (the method the
contributing docs already document) so hatch runs on the runner's normal
Python with a working pip on every OS. uv (from setup-uv) is still used as
the env installer.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
0 commit comments