`.lock` created in the wrong place on NixOS

[akaihola]

On NixOS, installing packages in a virtualenv fails with Read-only file system if

• either virtualenv was created using uv venv,
• or package install is attempted using uv pip install.

See also #4450, probably related but on macOS. This comment is probably relevant:

The fact that python from nix store isn't treated as a system interpreter isn't really an issue imo, as we can easily set the UV_PYTHON env dynamically in a derivation.

The real issue is the fact that uv wants to create a .lock file in there, but /nix/store is read-only, so that won't be possible.

---

The four cases and their success/failure status:

	python -m venv .venv	uv venv
pip install -U pip	:green_circle: success	:red_circle: FAIL
uv pip install -U pip	:red_circle: FAIL	:red_circle: FAIL

Terminal output for the four cases:

:green_circle: python -m venv / pip:

```shell $ python -m venv .venv $ source .venv/bin/activate $ pip install -U pip Requirement already satisfied: pip in ./.venv/lib/python3.12/site-packages (24.0) Collecting pip Using cached pip-24.2-py3-none-any.whl.metadata (3.6 kB) Using cached pip-24.2-py3-none-any.whl (1.8 MB) Installing collected packages: pip Attempting uninstall: pip Found existing installation: pip 24.0 Uninstalling pip-24.0: Successfully uninstalled pip-24.0 Successfully installed pip-24.2 ```

:red_circle: uv venv / pip:

```shell Using Python 3.12.4 interpreter at: /nix/store/pnavhjx4pdya95nx2apl2yxz6x46snh2-python3-3.12.4-env/bin/python3.12 Creating virtualenv at: .venv Activate with: source .venv/bin/activate $ source .venv/bin/activate $ pip install -U pip Requirement already satisfied: pip in /nix/store/pnavhjx4pdya95nx2apl2yxz6x46snh2-python3-3.12.4-env/lib/python3.12/site-packages (24.0) Collecting pip Using cached pip-24.2-py3-none-any.whl.metadata (3.6 kB) Using cached pip-24.2-py3-none-any.whl (1.8 MB) Installing collected packages: pip Attempting uninstall: pip Found existing installation: pip 24.0 WARNING: Could not access 'pyvenv.cfg' despite a virtual environment being active. Assuming global site-packages is not accessible in this environment. Uninstalling pip-24.0: ERROR: Could not install packages due to an OSError: [Errno 30] Read-only file system: '/nix/store/pnavhjx4pdya95nx2apl2yxz6x46snh2-python3-3.12.4-env/bin/pip' ```

:red_circle: python -m venv / uv pip:

```shell $ python -m venv .venv $ source .venv/bin/activate $ uv pip install -U pip error: failed to create file `/nix/store/pnavhjx4pdya95nx2apl2yxz6x46snh2-python3-3.12.4-env/.lock` Caused by: Read-only file system (os error 30) ```

:red_circle: uv venv / uv pip:

```shell $ uv venv Using Python 3.12.4 interpreter at: /nix/store/pnavhjx4pdya95nx2apl2yxz6x46snh2-python3-3.12.4-env/bin/python3.12 Creating virtualenv at: .venv Activate with: source .venv/bin/activate $ source .venv/bin/activate $ uv pip install -U pip error: failed to create file `/nix/store/pnavhjx4pdya95nx2apl2yxz6x46snh2-python3-3.12.4-env/.lock` Caused by: Read-only file system (os error 30) ```

---

Work-around using UV_PYTHON=$VIRTUAL_ENV/bin/python

The work-around only fixes one of the cases:

	python -m venv .venv	uv venv
pip install -U pip	:green_circle: success	:red_circle: FAIL
uv pip install -U pip	:green_circle: success (with work-around)	:red_circle: FAIL

:green_circle: python -m venv / uv pip:

```shell $ python -m venv .venv $ source .venv/bin/activate $ export UV_PYTHON=$VIRTUAL_ENV/bin/python $ uv pip install -U pip Resolved 1 package in 100ms Prepared 1 package in 0.53ms Uninstalled 1 package in 39ms ░░░░░░░░░░░░░░░░░░░░ [0/1] Installing wheels... Installed 1 package in 38ms - pip==24.0 + pip==24.2 ``` ---

[charliermarsh]

In the third example, what "is" /nix/store/pnavhjx4pdya95nx2apl2yxz6x46snh2-python3-3.12.4-env? Is that the path to the system Python? Or the virtual environment?

[akaihola]

what "is" /nix/store/pnavhjx4pdya95nx2apl2yxz6x46snh2-python3-3.12.4-env

It's what pkgs.python3.withPackages created.

Reading #4450 more carefully, that seems to be at the heart of the issue: running uv with a "clean" pkgs.python3 seems to work ok, but the "dirty" pkgs.python3.withPackages derivation confuses uv. See this comment from @Rubikoid.

My use case for withPackages is to get binary dependencies for Playwright into the environment. I do install a specific Playwright version with Pip once those are in place.

It seems installing both pkgs.python3 and pkgs.python3.withPackages and running uv with pkgs.python3 may work just fine. I'll need to verify that Playwright actually works, too.