How to use magical py3.10-<Env> prefixes with tox-uv?

[dimaqq]

Here's my tox config, in summary:

[testenv:py{3.8,3.10,3.12}-unit]
base=unit

[testenv:unit]
description = Run unit tests in parallel without coverage
passenv = ...
dependency_groups = unit, xdist
commands = pytest

I'm doing this because we want to run unit tests against a variety of Pythons.

This mostly works, but not quite:

tox -e unit works perfectly:

> tox -e unit -- -k asjklasdkjl
unit: venv> /Users/dima/.local/share/uv/tools/tox/bin/uv venv -p /Users/dima/.local/share/uv/tools/tox/bin/python --allow-existing --python-preference system /code/operator/.tox/unit
unit: uv-sync> uv sync --locked --python-preference system --no-default-groups --group unit --group xdist -p /Users/dima/.local/share/uv/tools/tox/bin/python

Note the uv-sync commands that generates this good venv:

> ls -lta .tox/unit/lib/python3.12/site-packages/
...
drwxr-xr-x@ 10 dima  staff     320 13 Jun 16:29 ops_scenario-7.23.0.dev0.dist-info/
...
drwxr-xr-x@ 11 dima  staff     352 13 Jun 16:29 ops-2.23.0.dev0.dist-info/
...
drwxr-xr-x@  9 dima  staff     288 13 Jun 16:29 ops_tracing-2.23.0.dev0.dist-info/
...
-rw-r--r--@  1 dima  staff      89 11 Jun 21:54 __editable__.ops-2.23.0.dev0.pth
-rw-r--r--@  1 dima  staff    3367 11 Jun 21:54 __editable___ops_2_23_0_dev0_finder.py
-rw-r--r--@  1 dima  staff      27 11 Jun 16:42 __editable__.ops_scenario-7.23.0.dev0.pth

The three packages in my uv workspace (ops, ops-scenario and ops-tracing) are installed from the workspace as editable.

tox -e py3.10-unit (or any pyXY-unit) doesn't quite work:

> tox -e py3.10-unit -- -k asjklasdkjl
py3.10-unit: venv> /Users/dima/.local/share/uv/tools/tox/bin/uv venv -p cpython3.10 --allow-existing --python-preference system /code/operator/.tox/py3.10-unit
py3.10-unit: install_dependency-groups> /Users/dima/.local/share/uv/tools/tox/bin/uv pip install 'eval-type-backport~=0.2; python_version < "3.10"' 'jsonpatch~=1.33' 'ops[testing,tracing]' 'pydantic~=2.10' 'pytest-xdist~=3.6' 'pytest~=8.0'

Note the different command, install_dependency-groups which generates slightly different venv:

> ls -lta .tox/py3.10-unit/lib/python3.10/site-packages/
...
drwxr-xr-x@ 13 dima  staff     416 13 Jun 16:31 scenario/
drwxr-xr-x@ 11 dima  staff     352 13 Jun 16:31 ops_tracing/
...
drwxr-xr-x@  9 dima  staff     288 13 Jun 16:31 ops-2.22.0.dist-info/
drwxr-xr-x@ 18 dima  staff     576 13 Jun 16:31 ops/
...
drwxr-xr-x@  7 dima  staff     224 13 Jun 16:31 ops_tracing-2.22.0.dist-info/
...

Where my workspace packages (ops, ops-tracing, ops-scenario) are suddenly downloaded from PYPI.

So, understandably, unit tests fail in pull requests that introduce new features (new tests are run against old code).

Here's the my project summary:

[project]
name = "ops"

[project.optional-dependencies]
testing = [
    "ops-scenario==7.23.0.dev0",
]
tracing = [
    "ops-tracing==2.23.0.dev0",
]

[dependency-groups]
unit = [
    "ops[testing,tracing]",
    "pytest~=8.0",
    # ...
]

[tool.uv.workspace]
members = ["tracing", "testing"]

[tool.uv.sources]
ops = { workspace = true }
ops-scenario = { workspace = true }
ops-tracing = { workspace = true }

Am I doing something wrong?
Is there perhaps a bug in the magical tox environments?

Full output: https://gist.github.com/dimaqq/09344704e422598dbae7c5a351275eac

[dimaqq]

Lock file check, if relevant:

2.23.0dev0 is present as a local/editable reference.
2.22.0 is not in the lock file at all, and somehow it gets installed in the "bad" case.

[dimaqq]

I was able to work around this by adding runner to the derived environments.

Before:

[tox]
...

[testenv]
runner = uv-venv-lock-runner
...

[testenv:py{3.8,3.10,3.12}-unit]
base=unit

[testenv:unit]
commands = ...

Evidently, testenv:unit inherits runner from testenv.
And testenv:py3.8-unit inherits commands from testenv:unit but not the runner.

After:

[tox]
...

[testenv]
runner = uv-venv-lock-runner
...

[testenv:py{3.8,3.10,3.12}-unit]
runner = uv-venv-lock-runner
base=unit

[testenv:unit]
commands = ...

Explicit runner solves the problem.

Ref: canonical/operator#1824