Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .python-version
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
3.14
2 changes: 1 addition & 1 deletion Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
29 changes: 29 additions & 0 deletions setup/create-venv.sh
Original file line number Diff line number Diff line change
@@ -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"
16 changes: 7 additions & 9 deletions setup/setup.bash
Original file line number Diff line number Diff line change
Expand Up @@ -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}")
Expand All @@ -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}"
Loading