Allow single constraints and overrides to be passed via the CLI

[zanieb]

The --constraint and --override flags should be updated to allow single constraints (in addition to the current behavior of accepting a file path), e.g., --constraint "foo>=0.1". In the --constraint case, this is mostly unambiguous — if there's a version specifier then we can treat it as a constraint. It is possible to have a file with that name, but it seems very unlikely in practice. In the --override case, we do allow overriding a dependency to have no specifiers, e.g., --override foo. I'm not sure if we should allow this via this interface? It seems nice to avoid the ambiguity. Historically, we've avoided inspecting the file system to determine the behavior of arguments and I think that is a good goal to maintain.

Previous discussion at

• Add support for requirements files in uv run #4973 (comment)
• --override not supported by uv run #4824 (comment)
• Allow --constraints and --overrides in uv tool install #9547 (comment)

[zanieb]

This proposal applies to both the uv pip interface (though it would differ from the upstream) and top-level interface (where --constraint and --override is only implemented for uv tool install at the moment but should be added elsewhere)

[notatallshaw-gts]

It is possible to have a file with that name, but it seems very unlikely in practice

You could always check for a file first and then fall back to see if it's a valid version specifier (that includes an operator, e.g. foo>=0.1 not just foo).

[zanieb]

You could always check for a file first and then fall back to see if it's a valid version specifier

This is the behavior we have historically avoided. We don't want the CLI behavior to change based on the state of the file system.

[notatallshaw-gts]

You could always check for a file first and then fall back to see if it's a valid version specifier

This is the behavior we have historically avoided. We don't want the CLI behavior to change based on the state of the file system.

Okay but constraints.txt is a valid requirement 😉.

>>> from packaging.requirements import Requirement
>>> Requirement('constraints.txt')
<Requirement('constraints.txt')>

And that is likely to be the name of a file, so I guess document this carefully on what the boundary conditions are between choosing a file or a requirement.

[notatallshaw-gts]

we do allow overriding a dependency to have no specifiers, e.g., --override foo

One last thing, the one use case to be aware of here is when specifying an always falsey environment marker, e.g. foo ; sys_platform == 'never'.

[zanieb]

Okay but constraints.txt is a valid requirement 😉.

Yeah so that's why I said we'd require a version specifier. A constraint without a version specifier doesn't do anything.

One last thing, the #4422 (comment) to be aware of here is when specifying an always falsey environment marker, e.g. foo ; sys_platform == 'never'.

Good point!

[charliermarsh]

Yeah, I guess we'd say: if it includes ;, =, <, or > (and not / or \) we treat it as a specifier.

[notatallshaw-gts]

:

Do you mean ;?

[charliermarsh]

Yes, sorry. (Edited.)

[charliermarsh]

@zanieb -- Just noticed one problem here... The values are technically space-delimited, so you can do UV_CONSTRAINTS="file1 file2" etc. That was initially for pip compatibility. But if they're space-delimited, it becomes much harder to do this... Not impossible, but definitely harder.

[zanieb]

Alas. I'm not sure what to do about that.

As a minor note, it's UV_CONSTRAINT.

One alternative option: we could align on the name in the pyproject.toml, which would be --dependency-constraint and --dependency-override. I don't love the setting name though (I find it non-obvious).