From 223b1347766636106164478a81507686089325ca Mon Sep 17 00:00:00 2001 From: Erich Blume Date: Tue, 14 Apr 2026 07:41:45 -0700 Subject: [PATCH] Document uv.lock as the source of devpi dependency in Dagger builds MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The lockfile bakes in devpi URLs — Dagger does a locked install, not fresh resolution. This is the mechanism behind the cold-cache failure. Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/how-to/operations/rebuild-minikube-cluster.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/how-to/operations/rebuild-minikube-cluster.md b/docs/how-to/operations/rebuild-minikube-cluster.md index 26207a7..3eaffd7 100644 --- a/docs/how-to/operations/rebuild-minikube-cluster.md +++ b/docs/how-to/operations/rebuild-minikube-cluster.md @@ -245,6 +245,8 @@ mise run services-check After a rebuild, devpi's package cache is empty. The first Dagger-based container build will trigger a flood of concurrent package downloads. Devpi uses lazy caching — it serves package metadata (simple index) immediately from upstream PyPI but fetches wheel files on demand. Under heavy concurrent load with a cold cache, the upstream fetch can race with the client request, causing devpi to return `no such file` (HTTP 404) for packages it knows about but hasn't finished downloading yet. +**Why devpi, not PyPI?** The repo's `uv.lock` was generated with devpi as the index, so every package source URL points at `pypi.ops.eblu.me`. Dagger's Python SDK runtime does a locked install (`uv sync`), not fresh resolution — it fetches from whatever URLs are in the lockfile. This is intentional (supply chain control), but means all builds — local and CI — depend on devpi being available and warm. + **Symptoms:** Forgejo Actions Dagger builds fail during module initialization with errors like: ``` Failed to download `googleapis-common-protos==1.74.0`