Request: Allow --output-file, --annotation-style, etc. multiple times, only use right-most

[AndydeCleyre]

requirements.in:

requests

$ uv pip compile requirements.in -o reqs1.txt -o reqs2.txt
error: the argument '--output-file <OUTPUT_FILE>' cannot be used multiple times
$ uv --version
uv 0.1.37
$ uname
Linux

I'm requesting that instead, the above command write output to (only) reqs2.txt, the latest instance of -o/--output-file on the command line. This is useful when using shell aliases or functions to wrap uv, when you specify a "default" output file in the alias or function, while allowing any invocation to easily override that default by specifying the option again, on the command line.

That's how pip-tools behaves, and I make use of that behavior.

[zanieb]

I think I'd find this behavior really confusing. What if we provided a UV_COMPILE_OUTPUT_FILE environment variable instead that you could override with the command line?

[zanieb]

This would also be resolved by #3049 / #1511 I presume?

[AndydeCleyre]

A file-based configuration or global configuration would not work for my case, which is functions that have their own defaults but are separate from any other ways the user wishes to use pip or uv.

With UV_COMPILE_OUTPUT_FILE, let me think: if uv is the backend being used I could add my own parsing of all the options, find and remove all output flags, use the last one to set UV_COMPILE_OUTPUT_FILE, and run my commands. It might be workable for my main case, but adds a lot of complication for the uv code path. Certainly not suitable for aliases.

FWIW, this is a very common convention (later options "win"), and is used not just by pip-tools but also pip itself. For example, the following command only uses the cache2 folder:

$ pip install --cache-dir="$PWD/cache1" requests --cache-dir="$PWD/cache2"

[zanieb]

Certainly not suitable for aliases.

I think you'd just write a simple bash function instead of an alias that sets a default value for the variable before calling into uv?

FWIW, this is a very common convention (later options "win"), and is used not just by pip-tools but also pip itself. For example, the following command only uses the cache2 folder:

I think with something like --cache-dir it's much clearer that a single cache directory can be used whereas with --output-file I would be uncertain if multiple output files will be written.

[AndydeCleyre]

FWIW here's maybe a more analogous option from pip:

$ pip install --dry-run --quiet --report=out1.json requests --report=out2.json

As expected, only out2.json is written.

[AndydeCleyre]

Similarly, both busybox wget and GNU wget use the latest-provided options for output file.

[AndydeCleyre]

I'll note that I am having similar troubles with e.g. --annotation-style, which I expected to work like it does in pip-tools (latest wins). I won't open a separate issue for that at this time, as it gets to the same larger question.

[hmc-cs-mdrissi]

I suspect part of this comes from argparse's design. Many python libraries use argparse/similar library. argparse's default behavior is last one wins with no awareness of meaning flag.

edit: Personally I like current duplicates are hard error over last one wins. My guess is it's commonness in python ecosystem is less that clis made choice individually, but argument handling libraries default choices made it common.

[AndydeCleyre]

Yup, argparse does it. So does Click. So does go-flags. And bazel. Looks like rustc will be doing it (if I'm interpreting that correctly).

[charliermarsh]

Is this the same? clap-rs/clap#4261

[AndydeCleyre]

Yeah, looks like exactly that.

[charliermarsh]

I think you can set this globally with something like https://docs.rs/clap/latest/clap/struct.Command.html#method.args_override_self.

[AndydeCleyre]

I probably should have posted these questions here instead of #3259:

Would either of the following make this change more palatable to those against it?

• Warn on stderr clarifying which option is being used, when single-use options occur more than once
• Only enable this when a new flag to do so is explicitly provided

[AndydeCleyre]

If this change is more likely to happen limited to a certain subset of flags, I'll list here the ones I most wish to override later (most likely to break usage of my project when subbing uv for pip-tools, though not at all exhaustive):

uv pip compile:

• --no-header
• --annotation-style
• -o

[AndydeCleyre]

@zanieb

Is there any form of this that has been suggested, or that you can come up with, which you're willing to allow?

[zanieb]

I don't think adding this to a subset of options would be great — consistency across the CLI seems important.

I do find your ecosystem examples convincing, but I still worry about the possibility of confusion. I'm just not seeing enough interest to merit changing this right now. (We have many issues with upvotes but nobody else has asked for this change yet)

[AndydeCleyre]

I expect it's just a matter of time, as my project was relatively quick to adopt and adapt to uv, so I hold out hope that this will change eventually. In the meantime I'll add one more widely used example: git.

$ alias gd="git diff --submodule=log"
$ gd --submodule=diff  # this works, as expected