Skip to content

Install uv so callers can package python Lambdas - #32

Merged
jumboduck merged 1 commit into
mainfrom
install-uv-for-lambda-packaging
Aug 24, 2026
Merged

Install uv so callers can package python Lambdas#32
jumboduck merged 1 commit into
mainfrom
install-uv-for-lambda-packaging

Conversation

@pbeckham

Copy link
Copy Markdown
Contributor

Part of kosli-dev/server#6561.

Adds a step to base.yml that installs uv on the runner, so a caller can package a python Lambda whose dependencies are a pyproject.toml plus a committed uv.lock.

Why

terraform-server is adding a python Lambda (a Celery queue sampler) built with terraform-aws-modules/lambda/aws. That module packages it by shelling out to uv export and uv pip install from a local-exec provisioner during apply. ubuntu-latest does not ship uv, so without this step the apply fails with a bare FileNotFoundError. Plans are unaffected: the prepare stage only hashes pyproject.toml and uv.lock.

What changed

base.yml is the only place this repo runs tf plan/tf applyplan.yml, apply.yml, detect-drift.yml all route through it — so one unconditional step covers every caller. It sits between the tf CLI PATH export and Check formatting, pinned to astral-sh/setup-uv@20cfd1bf... (v10.0.1).

Verification

uv export --python python3.13 --no-dev --frozen and uv pip install --python python3.13 --system --no-compile --target=. were run by hand against the consumer's real pyproject.toml and uv.lock: export resolves redis==6.4.0 with hashes and omits the dev-only fakeredis; install lands redis/ plus dist-info. test.yml runs actionlint and pytest on PRs to main, validating that base.yml still parses.

🤖 Generated with Claude Code

terraform-server's queue sampler (kosli-dev/server#6561) is a python
Lambda whose dependencies are declared in a pyproject.toml with a
committed uv.lock. terraform-aws-modules/lambda/aws builds that package
by shelling out to `uv export --no-dev --frozen` and `uv pip install
--python python3.13 --system --target .` from the local-exec provisioner
on `null_resource.archive`, so the tooling has to exist on this runner
or the apply cannot produce a zip.

Plans are unaffected either way: the module's prepare stage hashes
pyproject.toml and uv.lock without running a resolver, which is why the
absence only shows up at apply. And because the caller commits uv.lock,
package.py skips its own "uv must be installed and available in PATH"
branch and goes straight to check_call, so the failure surfaces as a
bare FileNotFoundError from a provisioner rather than as advice.

The step is unconditional rather than an input. It costs a couple of
seconds on runs that do not need it, and threading a boolean through
plan.yml, apply.yml and detect-drift.yml to save that would spread one
caller's packaging choice across four files.

uv's own version is deliberately unpinned while the action is SHA
pinned. What ends up in a deployment package is decided by the caller's
uv.lock and the hashes recorded in it, so a newer resolver reading the
same frozen lock produces the same bytes. Pinning it here would add a
bump chore to a workflow shared by every terraform repository.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@jumboduck
jumboduck merged commit 9ba24ac into main Aug 24, 2026
1 check passed
@jumboduck
jumboduck deleted the install-uv-for-lambda-packaging branch August 24, 2026 12:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants