Skip to content

Remove the climate-lama-engine git pin once v0.4.0 lands on PyPI

Status: Done (2026-05-02) Owner: backbone maintainers Tracking issue: #289 (closed) Source: temporary [tool.uv.sources] block in pyproject.toml (see comment at lines 136-138) pinning climate-lama-engine to a private-repo git revision.

The backbone currently depends on climate-lama-engine via a git URL pointing at a specific commit on main:

[tool.uv.sources]
climate-lama-engine = { git = "https://github.com/CortoMaltese3/climate-lama-engine.git", rev = "75fd63bf..." }

This was a 3-day bridge added on 2026-04-28 because engine v0.4.0 was tagged on main but had not yet been published to PyPI (the publish workflow was blocked by an exhausted GitHub Actions quota that resets 2026-05-01). The engine repository is private, so this git pin breaks docker compose up --build on any host without GitHub credentials wired into the build.

This doc is the runbook for removing the pin once v0.4.0 is on PyPI.


When to start

Trigger: climate-lama-engine version 0.4.0 (or higher) is published on PyPI. Check with:

curl -s https://pypi.org/pypi/climate-lama-engine/json | jq -r '.releases | keys[]'

Or:

pip index versions climate-lama-engine

Earliest expected date: 2026-05-01 (Actions quota reset). Track engine publish status in CortoMaltese3/climate-lama-engine#19.

Do not start before that. If v0.4.0 is not on PyPI yet, removing the [tool.uv.sources] block will resolve to 0.3.x and silently downgrade the engine, breaking compute jobs that rely on 0.4.0 features.


Steps

  1. Confirm v0.4.0 is on PyPI:
curl -s https://pypi.org/pypi/climate-lama-engine/0.4.0/json | jq -r '.info.version'

Must print 0.4.0. If it 404s, stop — the publish hasn't landed yet.

  1. Bump the floor in pyproject.toml. Find the worker extra (around line 67) and change:
"climate-lama-engine>=0.3.0",

to:

"climate-lama-engine>=0.4.0",
  1. Remove the [tool.uv.sources] block along with the bridge comment immediately above it (lines 136-140 as of 2026-04-28):
# Bridge: engine 0.4.0 is on main but not yet published to PyPI ...
# ... tracked in climate-lama-engine#19).
[tool.uv.sources]
climate-lama-engine = { git = "...", rev = "..." }

Delete the entire block. If [tool.uv.sources] has no other entries, the header goes too.

  1. Refresh both lockfiles:
uv lock
(cd sdk/python && uv lock)

The backbone uv.lock and sdk/python/uv.lock both currently reference the git source; both need to be regenerated. Sanity-check the diff: the climate-lama-engine entry in each lockfile should now have source = { registry = "https://pypi.org/simple" } (or similar) instead of source = { git = "..." }.

  1. Drop git from the two Dockerfiles — it was only added to support the git pin. Remove the git \ line from:

  2. docker/core.Dockerfile (in the apt-get install block)

  3. docker/worker.Dockerfile (in the apt-get install block)

  4. Build clean and verify the worker image actually pulls the engine from PyPI:

docker compose build --no-cache worker
docker compose run --rm worker python -c "import climate_lama_engine, sys; print(climate_lama_engine.__version__)"

The version printed must be 0.4.0 or higher.

  1. Run the test suite locally:
uvx ruff check src/ tests/
uv run pytest

Both must pass. If any worker/engine integration test fails with an AttributeError or version-related error, the engine API may have shifted between the pinned commit and the published 0.4.0 — investigate before continuing.

  1. Run the full stack to catch runtime regressions the test suite misses:
docker compose up --build
python scripts/demo.py

The demo must complete end-to-end. (Per repo convention, demo runs are part of the validation surface for any dependency change touching the worker.)

  1. Commit on a feature branch:
git checkout -b chore/remove-engine-git-pin
git add pyproject.toml uv.lock sdk/python/uv.lock docker/core.Dockerfile docker/worker.Dockerfile
git commit -m "chore(worker): pull climate-lama-engine 0.4.0 from PyPI"

Body should note: "Removes the temporary git pin and the git apt dependency from both Dockerfiles. Closes #."

  1. Open a PR referencing the tracking issue:

    gh pr create --fill --base main
    

    Wait for CI to pass before merging.


Workaround for self-hosters blocked right now

If you need docker compose up --build to work before v0.4.0 is on PyPI and you do not have access to the private engine repo, the only options are:

  • Wait until v0.4.0 publishes (preferred — usually a few days).
  • Pull the published images instead of building locally:
CLIMATE_LAMA_TAG=<latest tag> docker compose pull api worker
docker compose up

This skips the build step entirely. See docs/ops/release-pipeline-followup.md for the release pipeline that publishes those images.

Wiring a GitHub Personal Access Token into the Docker build via BuildKit secrets is technically possible but is not a supported path — the engine repo is expected to either go public or be reachable via PyPI, and adding PAT plumbing to the Dockerfiles would create an authentication surface we then have to remove.


Verify (definition of done)

  • [x] pyproject.toml worker extra requires climate-lama-engine>=0.4.0.
  • [x] [tool.uv.sources] block and bridge comment are gone from pyproject.toml.
  • [x] uv.lock and sdk/python/uv.lock reference the PyPI registry, not git.
  • [x] git is no longer installed in docker/core.Dockerfile or docker/worker.Dockerfile.
  • [x] docker compose build --no-cache succeeds on a host without GitHub credentials.
  • [x] python scripts/demo.py completes against a fresh stack.
  • [x] CI green on the PR; merged to main.
  • [x] Tracking issue closed.

Landed via feef0a0 (pyproject + uv.lock) and #303 (drop git from Dockerfiles).