chore: add virtualenv and uv to selenium container

[ssbarnea]

This should fix the issue of newer python-venv vscode extension failing to find any tools/environments to use.

[Copilot]

Pull request overview

Updates the selenium container image to include virtualenv and the uv toolchain, enabling installation of the project wheel via uv pip and provisioning multiple Python runtimes inside the container.

Changes:

• Prepends /home/selenium/.local/bin to PATH in the container environment.
• Adds python3-virtualenv to the installed RPM package set.
• Installs uv, uses it to install the ansible_dev_tools wheel, and installs multiple Python versions via uv python install.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

uv python install ... will download multiple interpreter distributions during the build, but this layer doesn’t use a BuildKit cache mount for uv’s download/cache directory. Adding a cache mount aligned to uv’s cache location (or setting UV_CACHE_DIR to a mounted path) can significantly speed up rebuilds and reduce network flakiness in CI.

[Copilot]

PATH is hard-coded to /home/selenium/.local/bin even though SELENIUM_HOME/HOME are already set. This makes the image harder to maintain if SELENIUM_HOME ever changes; prefer deriving the path from SELENIUM_HOME (or HOME) for consistency with the rest of the file.

Suggested change

	PATH=/home/selenium/.local/bin:${SELENIUM_HOME}/firefox:/opt/google/chrome:${PATH}
	PATH=${SELENIUM_HOME}/.local/bin:${SELENIUM_HOME}/firefox:/opt/google/chrome:${PATH}

[Copilot]

The build cache mount --mount=type=cache,target=/.cache/uv is unlikely to be used here: this step runs pip install, which caches under the pip cache dir (typically /root/.cache/pip), and uv itself defaults to ~/.cache/uv (i.e. /root/.cache/uv) unless UV_CACHE_DIR/XDG_CACHE_HOME is set. As written, this can both miss build caching and leave pip caches in the image layer; consider mounting the actual pip/uv cache locations or setting UV_CACHE_DIR to match the mounted path, and/or disabling pip caching for this install.

Suggested change

	RUN --mount=type=cache,target=/.cache/uv python3 -m pip install --root-user-action=ignore uv
	RUN --mount=type=cache,target=/.cache/uv PIP_CACHE_DIR=/.cache/uv python3 -m pip install --root-user-action=ignore uv

[Copilot]

The comment says "install uv and all supported python versions with it", but this step only installs uv; the Python versions are installed later (after switching to USER 1001). Please update the comment to reflect what happens in this stage to avoid confusion during future maintenance.

Suggested change

	# install uv and all supported python versions with it
	# install uv package manager (Python versions are installed later as non-root user)

[Copilot]

uv python install 3.10 3.11 3.12 3.13 3.14 introduces a Python 3.14 runtime in the image, but the repo’s declared/tested support appears to stop at 3.13 (e.g. classifiers in pyproject.toml and CI max_python in .github/workflows/tox.yml). To keep a single source of truth for supported versions (and avoid unexpected bloat/build failures if 3.14 isn’t intended), please align this list with the project’s supported versions or document why 3.14 is required here.

Suggested change

	RUN uv python install 3.10 3.11 3.12 3.13 3.14
	RUN uv python install 3.10 3.11 3.12 3.13

[Copilot]

python3 -m pip install --root-user-action=ignore uv pulls the uv package from PyPI without any version pinning or integrity verification, creating a supply chain risk. An attacker who compromises the uv distribution (or intercepts traffic) could get arbitrary code executed in this image build and at runtime when uv is invoked. Pin uv to a specific, trusted version (and ideally verify its integrity via a hash or lockfile) to ensure builds are deterministic and not exposed to unexpected upstream changes.