Subprocess-based tests (e.g. Examples) fail depending on environment tool due to missing PYTHONPATH

[planetf1]

Subprocess-based tests (e.g. Examples) fail depending on environment tool due to missing PYTHONPATH

Description

Tests that spawn fully isolated Python subprocesses (like the examples in docs/examples/conftest.py and heavy GPU tests in test/conftest.py) use subprocess.Popen([sys.executable, ...]).

While sys.executable ensures the correct virtual environment Python is used, it does not guarantee the subprocess can resolve the mellea package.

• If the environment was set up with a package manager that explicitly injects an editable install into site-packages (e.g., uv pip install -e . during a conda setup script), the subprocess finds mellea successfully.
• If the environment relies on transient runtime path resolution (e.g., running uv run pytest directly, where pytest dynamically adds the CWD to sys.path in-memory), the spawned subprocess does not inherit this in-memory sys.path and crashes with ModuleNotFoundError: No module named 'mellea'.

Fix

To make the test harness fully resilient regardless of how the dependencies were materialized (conda, uv sync, pip, vs pure uv run), we should explicitly inject the repository root into PYTHONPATH before spawning these subprocesses:

import pathlib
import os

# Robustly resolve the repo root from conftest.py's known location
repo_root = str(pathlib.Path(__file__).parent.parent.parent.resolve())
env = os.environ.copy()
env["PYTHONPATH"] = f"{repo_root}{os.pathsep}{env.get('PYTHONPATH', '')}"

process = subprocess.Popen([sys.executable, ...], env=env)

Environment Context

We hit this when running uv run --all-extras --group dev pytest -m huggingface -v via an LSF job on a shared cluster with a pre-existing conda environment. Regular tests passed, but the docs/examples/ subprocesses all failed with ModuleNotFoundError.