uv lock(): support non-quiet output from the .run target

[psalaberria002]

Problem

The lock() macro in @rules_python//python/uv:lock.bzl generates a .run target whose shell script hardcodes --no-progress --quiet when invoked via bazel run:

exec '.../uv' 'lock' '--no-python-downloads' '--no-cache' '--project' '.' '--python' '...' '--no-progress' '--quiet' "$@"

This means all uv output is suppressed. Passing --verbose does not work — uv rejects --quiet and --verbose together with an error:

error: the argument '--quiet...' cannot be used with '--verbose...'

Use case

We call bazel run //:uv_lock.run -- --check from a just recipe to verify that uv.lock is consistent with pyproject.toml (a developer workflow check, not a CI test). With --quiet hardcoded, there is no feedback on success and no details on failure about what changed. We want uv's normal output (e.g. "Resolved 562 packages in 5.75s" on success, or the list of changed packages on failure).

Proposed solution

Add an optional quiet attribute to the lock() macro (defaulting to True to preserve existing behavior) that controls whether --quiet and --no-progress are passed to the .run script:

lock(
    name = "uv_lock",
    srcs = ["pyproject.toml", "uv.lock"],
    out = "uv.lock",
    quiet = False,  # show uv output when running bazel run //:uv_lock.run
)

Workaround

We currently work around this by adding a custom Starlark rule (uv_lock_check_run) that inherits the same runfiles as .run but finds the uv binary at runtime and calls it directly without --quiet. This wrapper exists solely because the attribute is not exposed.

[aignas]

I am happy with accepting a PR with suggested fix of having a quiet attribute. My thinking is that we should retain the --quite in the regular build target so that the stderr is not present during bazel build. So in a sense an alternative that would be equally good is to just add --quiet and --no-progress only to the build action.

That way the .run should act as you expect.