Repository navigation
uv lock warning suggests non-existent --no-frozen flag #19290
Description
Summary
When UV_FROZEN=1 is set (or frozen is set in workspace configuration), running uv lock emits a hint that doesn't work:
UV_FROZEN=1 uv lock
warning: The lockfile at `uv.lock` was only checked for validity, not whether it is up-to-date, because `UV_FROZEN=1` was provided; use `--no-frozen` or `--check` instead
UV_FROZEN=1 uv lock --no-frozen
error: unexpected argument '--no-frozen' found
tip: a similar argument exists: '--frozen'
Usage: uv lock --check-exists
For more information, try '--help'.
That hint comes from https://github.com/astral-sh/uv/blob/0.11.9/crates/uv/src/commands/project/lock.rs#L233
Platform
Linux 7.0.0-14-generic x86_64
Version
uv 0.11.8 (x86_64-unknown-linux-musl)
Python version
Python 3.14.4
Activity
nooscraft commentedon May 5, 2026
Yes, the suggestion is wrong.
uv lockdoesn't have a--no-frozenflag (unlikeuv sync/uv run); onuv lock,--frozenis just an alias for--check-exists. Looks like the env/config branch of the warning inlock.rswas modelled on the other subcommands' flag inventory. Introduced in #17859.The ideal fix would be to drop
--no-frozenfrom that message so it matches the--frozenCLI branch right above (use --check instead). While I was looking, theConfigurationhalf of that branch isn't actually reachable today. There's notool.uv.frozenfield inGlobalOptions, andFlag::from_config("frozen")is never constructed anywhere in the tree (onlyofflineis). The warning only ever fires on theUV_FROZENpath in practice; the workspace-config wording is plumbing without a source.fix(lock): warning suggests non-existent --no-frozen flag (astral-sh#…
build(deps): update uv to v0.11.13
feat(github-release): update release uv ( 0.10.9 → 0.11.17 ) (#34)
feat(github-release): update release uv ( 0.10.9 → 0.11.19 ) (#43)