stroblme 340315b6e9 parity_venv.sh: swap the environment it claims to swap ...

The script exported UV_PROJECT_ENVIRONMENT and then reached for `uv pip`, which
does not honour it — it discovers an environment the way pip does, so the
uninstall and install landed in the app's own .venv. The sanity check that
follows could not notice, because `uv run` *does* honour the variable and so
read the untouched parity venv. Net effect: the swap happened in the wrong
place and reported success. Inc 0's parity claim never exercised the parity
venv at all.

Two fixes, since the second only surfaced once the first was in:

- `uv pip` gets --python pointing at the parity venv.
- everything afterwards runs that venv's interpreter directly. `uv run` re-syncs
  the environment against the app's manifest before running, and the manifest
  still asks for cadquery-ocp-novtk, so it reinstalled the stock wheel on top of
  the swap. The usage note at the top said to drive the app's tests that way
  too; it now says to use the venv's python.

Also pins `uv sync --python 3.12`, so the parity venv keeps resembling what the
image ships instead of following whatever interpreter is newest on the box, and
turns the sanity print into an assertion on __occt_version__ — an attribute
only our wheel defines, which makes it a check that the swap landed.

Verified end to end against the published 7.9.3.1.dev2: installs anonymously
from the Gitea index, 31 modules, ocp suite 48 passed, and the app's main venv
is left on stock.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfriM8XUkn7uYf5Dwe2xo6

2026-08-10 19:59:18 +02:00

3.5 KiB

Executable File

Raw Blame History

View Raw