[tonyandrewmeyer]

Adds a private scenario._charm_requirements module that installs a charm's Python dependencies the way the build plugin in its charmcraft.yaml would, so that a charm in a multi-charm test can run in a virtual environment with its own dependencies rather than the test's. Nothing uses it yet (building and caching the environment is a later PR in the series).

• Only the python and uv plugins are supported. The charm and reactive plugins are deprecated, and poetry is planned to be done when requested. A charm with no charmcraft.yaml is also an error, even if it has a uv.lock, because charmcraft can't build it either. So is a part using a plugin that isn't one of craft-parts' built-in ones, even next to a python or uv part, because it might install Python dependencies too. Every error is a private RuntimeError subclass, which will move onto the public error when there's a caller to raise it from.
• Rather than reading requirements files itself, the module gives pip and uv the same arguments charmcraft does, from the same directory (the part's source and source-subdir). For the python plugin that's pip install --no-deps with the part's python-constraints, python-requirements and python-packages, in charmcraft's order, so relative paths and nested -r files resolve exactly as they do in a pack.
• For the python plugin, the charm libraries' PYDEPS aren't included, because charmcraft's python plugin doesn't install them either (it installs with --no-deps and expects the requirements file to be complete). This was incorrect in the spec.
• For the uv plugin, this runs uv export with the options charmcraft's uv plugin passes to uv sync (--no-dev, --no-editable, and the part's extras and groups), and --no-emit-project to match charmcraft's --no-install-project. It uses --locked, so a stale uv.lock is an error rather than being re-locked as charmcraft pack would.
• ops, ops-scenario and ops-tracing are uninstalled afterwards, whatever the plugin: the charm's environment will use the test's own copies, so the versions always match. (ops-tracing pins an exact ops version, so a charm's locked copy wouldn't work with the test's ops.) Because of that, installing into the environment the tests are running in is refused.

The install tests build their own wheels, and the uv tests lock a charm with path dependencies, so they don't need an index or the network. They do need uv on PATH, as the test environments have.

[tonyandrewmeyer]

Drive-by.

[dwilding]

Before I start reviewing this in detail, I wonder, does this deserve to be a standalone tool?

[tonyandrewmeyer]

Before I start reviewing this in detail, I wonder, does this deserve to be a standalone tool?

Do you have other use-cases in mind? (Beyond OP089's one.)

[dwilding]

Do you have other use-cases in mind? (Beyond OP089's one.)

No, I was just curious 🙂

[hpidcock]

@chapman-von-monty review this PR.

[chapman-von-monty]

Verdict: Request changes

P2 — Avoid exposing credentials and unbounded subprocess output in dependency-resolution errors. In testing/src/scenario/_charm_requirements.py (pip path around lines 121–124 and uv path around 306–314), exceptions include raw pip arguments and subprocess stderr. Requirements may contain credential-bearing direct URLs, and stderr can include those URLs or arbitrarily large output. This can leak secrets into logs and produce unwieldy diagnostics.

Please sanitize or omit sensitive arguments/output and bound any retained stderr before including it in the raised error. Add targeted tests verifying credential-bearing URLs are not present in errors and long stderr is truncated or otherwise bounded.

The existing PR comment is an unrelated drive-by; this is the substantive review.

[chapman-von-monty]

Follow-up review at head d07080b70aa81662442183cc80cca2ba8e3ea188: the previously reported P2 remains unresolved—subprocess errors can expose raw pip arguments and unbounded output. I found no additional issues in the seven-commit update. See my earlier review for the requested fix and regression tests: #2880 (comment)