Summary
Please add an optional feature to prefer the uv tool (when available on PATH) to create the virtual environment used to run playbooks/tests. The idea is to detect uv at runtime and use it to create the venv where the playbook is executed, falling back to the existing venv logic when uv is not present.
Background / motivation
Currently the framework sets up a virtual environment via an internal implementation (python3 -m venv / venv module). Some environments (CI, developer machines) install uv (or other venv helper tools) which may provide faster env creation, better reproducible environment handling, caching, and centralized management. Allowing uv to be used when present improves performance and integrates with developer workflows.
Proposed behaviour
- At startup of
PlaybookRunner.setup_virtualenv() detect whether an executable named uv is available via shutil.which("uv") (or equivalent).
- If
uv is present, call it to create the virtual environment at the expected path (the same path the runner currently uses), and then continue with the current bootstrapping (installing requirements, calling module_mocker.setup_mocks(), etc.).
- If
uv is not present, fall back to the existing python3 -m venv / builtin behaviour.
- The change should be opt-in via config flag if you prefer explicit control, but safe default is: prefer
uv when present.
Compatibility and safety
- Backwards compatible: if
uv is not installed, behaviour is unchanged.
- Keep existing semantics for
use_virtualenv marker and virtualenv.path.
- Ensure error handling: if
uv fails to create the env, fall back to builtin venv and surface a warning; do not abort tests silently.
Implementation notes (suggested)
- Add a small helper in
core/playbook_runner.py that encapsulates env creation and abstracts over uv vs builtin venv.
- Unit tests: mock
shutil.which and assert the runner calls uv when available and falls back otherwise.
- Integration test: if CI image can include
uv optionally, verify the created env works and module_mocker.setup_mocks() is still invoked correctly.
Why this will help
- Better developer ergonomics for teams that adopt
uv.
- Potentially faster environment creation and improved caching/reproducibility.
Open questions
- Does the project want this behaviour to be automatic or opt-in via a config flag? I suggested automatic detection with a config override.
/cc @maintainers
Summary
Please add an optional feature to prefer the
uvtool (when available on PATH) to create the virtual environment used to run playbooks/tests. The idea is to detectuvat runtime and use it to create the venv where the playbook is executed, falling back to the existingvenvlogic whenuvis not present.Background / motivation
Currently the framework sets up a virtual environment via an internal implementation (python3 -m venv / venv module). Some environments (CI, developer machines) install
uv(or other venv helper tools) which may provide faster env creation, better reproducible environment handling, caching, and centralized management. Allowinguvto be used when present improves performance and integrates with developer workflows.Proposed behaviour
PlaybookRunner.setup_virtualenv()detect whether an executable nameduvis available viashutil.which("uv")(or equivalent).uvis present, call it to create the virtual environment at the expected path (the same path the runner currently uses), and then continue with the current bootstrapping (installing requirements, callingmodule_mocker.setup_mocks(), etc.).uvis not present, fall back to the existingpython3 -m venv/ builtin behaviour.uvwhen present.Compatibility and safety
uvis not installed, behaviour is unchanged.use_virtualenvmarker andvirtualenv.path.uvfails to create the env, fall back to builtin venv and surface a warning; do not abort tests silently.Implementation notes (suggested)
core/playbook_runner.pythat encapsulates env creation and abstracts overuvvs builtin venv.shutil.whichand assert the runner callsuvwhen available and falls back otherwise.uvoptionally, verify the created env works andmodule_mocker.setup_mocks()is still invoked correctly.Why this will help
uv.Open questions
/cc @maintainers