astral-sh/uv

Show a better error when a uv lockfile is used in `-r`

Open

#16192 opened on Oct 8, 2025

View on GitHub
 (3 comments) (3 reactions) (0 assignees)Rust (84,934 stars) (3,111 forks)batch import
error messageshelp wanted

Description

e.g., if you try to use uv lock --script action.py then -r action.py.lock

error: Couldn't parse requirement in `action.py.lock` at position 0
  Caused by: no such comparison operator "=", must be one of ~= == != <= >= < > ===
version = 1
        ^^^

We can do better by detecting our own lockfile format

Contributor guide

Tech stack
rust
Domain
clideveloper experience
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Basic RustUnderstanding of uv lockfile format
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
70
Research direction
The issue is about improving error handling when a user mistakenly passes a uv lockfile to the ` r` flag. Start by examining how ` r` arguments are parsed in the CLI, likely in the `uv` crate's argument handling or in the lockfile parser. Look for where the error message 'Couldn't parse requirement' is generated and trace back to understand how file types are detected. The goal is to detect if the file is a uv lockfile by checking its contents (e.g., the presence of 'version = 1' header) and emit a clearer, user friendly error message.