Tatsh / sbclaude / 32103106778

100%

push

github

venv: give the box its own virtualenv and leave the project's alone

A virtualenv records the absolute path of the interpreter it was built
against. The host's does not exist in the image and the box's does not
exist on the host, so sharing .venv between them leaves whichever ran
last pointing at an interpreter that is not there. Both this repository
and deltona had a dangling .venv/bin/python from exactly that.

The box now uses .sbclaude-venv:

- UV_PROJECT_ENVIRONMENT is set to the relative name rather than an
  absolute path. uv resolves a relative value against whichever project
  it is working on, so every project the box touches gets a virtualenv
  beside its own pyproject.toml. The absolute path it held before named
  one project for the whole container, so a sync run in a second project
  installed into the first project's environment and replaced what was
  in it.
- Beside the project rather than under /tmp, because the container is
  always run with --rm and anything in its own filesystem is rebuilt
  from nothing on every start.
- /.sbclaude-venv/ goes in .git/info/exclude rather than .gitignore. It
  is a local artefact of how this checkout is being worked on, not a
  fact about the project that every other clone should carry.

The host's .venv is bind-mounted read-only over itself. The project
mount is read-write so the agent can edit code, which otherwise leaves
the host's interpreter and installed packages writable by an agent
running with permissions skipped.

The entrypoint provisions the virtualenv on start when it finds a
pyproject.toml, setup.py, setup.cfg, requirements.txt or Pipfile, and
puts its bin directory on PATH. Provisioning is best-effort: a project
that cannot resolve here still gets a session.

One dependency that cannot build fails the whole sync, which would leave
the box with no test runner and no linter over a package it was never
going to use. Some cannot build at any price: pygobject 3.56 wants
girepository-2.0, ... (continued)

93 of 93 branches covered (100.0%)

Branch coverage included in aggregate %.

34 of 40 new or added lines in 3 files covered. (85.0%)

695 of 701 relevant lines covered (99.14%)

4.96 hits per line