Manage Python versions

* Add script for creating venvs in a way that
   * uses uv without requiring it to be installed
   * controls the used Python version with .python-version file
* Use the script in Makefile and action setup
* Be sure to treat Windows as the special case it is with regards to
  venv bin directory

Signed-off-by: Jussi Kukkonen <[email protected]>

Author: jku

.python-version

@@ -0,0 +1 @@
+3.14

Makefile

@@ -4,7 +4,7 @@ all:
 	@echo "Run my targets individually!"
 
 .venv/pyvenv.cfg: requirements/dev.txt
-	uv venv
+	setup/create-venv.sh .venv
 	. ./.venv/bin/activate && \
 	uv pip install -r requirements/dev.txt
 

setup/create-venv.sh

@@ -0,0 +1,29 @@
+# uv allows us to easily manage python versions for our venvs... but uv is not always available.
+# Assume that there is *some* Python available and use a bootstrap venv using the system python to
+#   1. install uv & the python we want (see .python-version)
+#   2. create the actual venv with the installed python
+#   3. install uv in the actual venv
+# Now the actual venv is ready to use
+
+if [ -z "$1" ]; then
+    echo "Error: No virtual environment path provided." >&2
+    echo "Usage: $0 <venv_path>" >&2
+    exit 1
+fi
+
+ENV=$1
+
+BOOTSTRAP_ENV=$(mktemp -d)
+python3 -m venv --clear "$BOOTSTRAP_ENV"
+
+# Annoying: Windows venvs use a different structure, for unknown reasons.
+if [ -d "$BOOTSTRAP_ENV/bin" ]; then
+  BIN="$BOOTSTRAP_ENV/bin"
+else
+  BIN="$BOOTSTRAP_ENV/Scripts"
+fi
+
+
+. "$BIN/activate" && pip install uv && uv venv --clear "$ENV" && VIRTUAL_ENV="$ENV" uv pip install uv
+touch "$ENV/bootstrap"
+rm -r "$BOOTSTRAP_ENV"

setup/setup.bash

@@ -38,9 +38,6 @@ if [[ "${0}" == "${BASH_SOURCE[0]}" ]]; then
 fi
 
 # Check the Python version, making sure it's new enough (3.9+)
-# The installation step immediately below will technically catch this,
-# but doing it explicitly gives us the opportunity to produce a better
-# error message.
 vers=$(python -V | cut -d ' ' -f2)
 maj_vers=$(cut -d '.' -f1 <<< "${vers}")
 min_vers=$(cut -d '.' -f2 <<< "${vers}")
@@ -51,19 +48,20 @@ min_vers=$(cut -d '.' -f2 <<< "${vers}")
 # `actions/setup-python`, then we might be using the distribution's Python and
 # therefore be subject to PEP 668. We use a virtual environment unconditionally
 # to prevent that kind of confusion.
-python -m venv "${GITHUB_ACTION_PATH}/.action-env"
+"${GITHUB_ACTION_PATH}/setup/create-venv.sh" "${GITHUB_ACTION_PATH}/.action-env"
 
 # Annoying: Windows venvs use a different structure, for unknown reasons.
 if [[ -d "${GITHUB_ACTION_PATH}/.action-env/bin" ]]; then
-  VENV_PYTHON_PATH="${GITHUB_ACTION_PATH}/.action-env/bin/python"
+  BIN="${GITHUB_ACTION_PATH}/.action-env/bin"
 else
-  VENV_PYTHON_PATH="${GITHUB_ACTION_PATH}/.action-env/Scripts/python"
+  BIN="${GITHUB_ACTION_PATH}/.action-env/Scripts"
 fi
 
-"${VENV_PYTHON_PATH}" -m pip install --requirement "${GITHUB_ACTION_PATH}/requirements/main.txt"
+. "$BIN/activate" && uv pip install --requirement "${GITHUB_ACTION_PATH}/requirements/main.txt"
 
-debug "sigstore-python: $("${VENV_PYTHON_PATH}" -m sigstore --version)"
+
+debug "sigstore-python: $("$BIN/python" -m sigstore --version)"
 
 # Finally, propagate VENV_PYTHON_PATH so we can actually kick-start
 # the extension from it.
-echo "venv-python-path=${VENV_PYTHON_PATH}" >> "${GITHUB_OUTPUT}"
+echo "venv-python-path=${BIN}/python" >> "${GITHUB_OUTPUT}"