`UV_FROZEN=0 uv lock --check` fails

[NellyWhads]

Summary

The environment variable resolution, for good reason, considers --frozen (UV_FROZEN=1) and --check (UV_LOCKED=1) to be conflicting.

However, the false/0 values should not cause conflicts.

For example, if in a managed repository, UV_FROZEN=1 is set up in the development environment to prevent accidental automatic re-locked updates, a linter should be able to use the command as titled.

A current work-around is to instead use env -u UV_FROZEN uv lock --check, however, the conflicting false/0 behavior is unintuitive.

Platform

MacOS 14, Ubuntu 22.04

Version

tested with >= 0.6.13

Python version

3.8 through 3.12

[heiner]

I can confirm this is still an issue

$ UV_FROZEN=1 uv lock --locked
error: the argument '--check' cannot be used with '--check-exists'

Usage: uv lock --check

For more information, try '--help'.
$ UV_FROZEN=0 uv lock --locked
error: the argument '--check' cannot be used with '--check-exists'

Usage: uv lock --check

For more information, try '--help'.
$ uv --version
uv 0.7.3

[zanieb]

This has the same cause as https://github.com/astral-sh/uv/issues/13316

[maxmynter]

I did a little digging into this. The exclusivity is enforced by Clap. https://github.com/astral-sh/uv/blob/3b8139526a8dc1f3bfd003b9ef215bd148025ce6/crates/uv-cli/src/lib.rs#L3378-L3386

From what I found in the Clap docs, it's not possible to declare conflicts on runtime values without custom validation logic. Alternatively, one could handle the values earlier in the lifecycle before they are passed in LockSettings::resolve.

If either is desired, let me know, I'm happy to suggest a PR.

[konstin]

Upstream bug: https://github.com/clap-rs/clap/issues/5591