Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

uv: lock() .run target for uv.lock omits existing lock and writes to runfiles

Geschlossen
  • Stimmt etwas nicht?
#4,339 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Ein zugehöriger Pull Request wurde bereits gemerged.

  • #4343 von @rickeylev — gemerged

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
build-system

Rechercherichtung

Start with _common_lock in python/uv/private/lock.bzl and the uv_lock.sh and uv_lock.bat launchers. Check how the existing lock is added to runfiles and how the launcher handles BUILD_WORKSPACE_DIRECTORY, then reproduce with the provided bazel run command. Done means the existing lock is available to uv and the command updates dev/uv.lock in the source tree.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Running bazel run <name>.run on a lock() target with a uv.lock output
(e.g. bazel run //dev:uv_lock.run -- --upgrade-package certifi==2026.1.4)
fails to update the workspace lockfile in place due to two bugs:

  1. Missing existing lock in runfiles: _common_lock in
    python/uv/private/lock.bzl passes ctx.files.existing_output to the build
    action's inputs, but omits it from _RunLockInfo.runfiles. Because uv
    runs in .runfiles/_main where no uv.lock is present, uv lock
    re-resolves all dependencies from scratch instead of incrementally updating
    the existing lock.
  2. Output written to .runfiles instead of the source tree: Unlike
    uv pip compile (which accepts --output-file), uv lock always reads and
    writes uv.lock in the project directory relative to its working directory.
    When BUILD_WORKSPACE_DIRECTORY is set, uv_lock.sh and uv_lock.bat
    execute uv immediately without linking or copying {{project_lock}} to
    ${BUILD_WORKSPACE_DIRECTORY}/{{src_out}}. The updated lockfile is written
    to bazel-bin/.../*.run.runfiles/_main/.../uv.lock, leaving the source tree
    untouched.
Reproduction
#!/usr/bin/env bash
set -euo pipefail

git checkout -- dev/uv.lock
bazel run //dev:uv_lock.run -- --upgrade-package certifi==2026.1.4

changes=$(git diff dev/uv.lock | grep -c '^-version = ' || true)
if [[ "$changes" -eq 1 ]]; then
    echo "PASS: dev/uv.lock updated 1 package as expected"
else
    echo "FAIL: expected 1 package updated in dev/uv.lock, got $changes"
    exit 1
fi

Running this prints:

FAIL: expected 1 package updated in dev/uv.lock, got 0

while bazel-bin/dev/uv_lock.run.runfiles/_main/dev/uv.lock contains a full
re-resolution of 18 packages.

Vorherrschende Sprache
Starlark
Sterne
688
Forks
728
Ø Merge
17 Std. 24 Min.
Gemergte PRs (30 T.)
131

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus bazel-contrib/rules_python

Alle Issues in bazel-contrib/rules_python

Ähnliche Issues

Weitere Issues zu Build System

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.