Support `UV_ONLY_BINARY` and `UV_NO_BINARY` environment variables
This is useful with cibuildwheel or some other complicated tools in the CI environment.
pip has similiar PIP_NO_BINARY and PIP_ONLY_BINARY: https://pip.pypa.io/en/latest/cli/pip_install/#cmdoption-no-binary
I think we've avoided this because we're not interested in supporting the pip syntax outside of the pip interface. Maybe we could namespace them e.g. UV_PIP_NO_BINARY in the meantime?
Some of them are available, though, like UV_CONSTRAINT, UV_INDEX_URL, UV_EXTRA_INDEX_URL, and UV_BREAK_SYSTEM_PACKAGES. I don't really care what it's called, but it would be nice to have, as you can't pass flags through inside cibuildwheel to every command.
@zanieb Please consider that other package managers also support this, since it's a genuinely useful feature for containerized builds, and not just a Pip feature.
@sanmai-NL we do support this via persistent configuration, e.g.,
- https://docs.astral.sh/uv/reference/settings/#no-binary
- https://docs.astral.sh/uv/reference/settings/#no-binary-package
- https://docs.astral.sh/uv/reference/settings/#no-build
- https://docs.astral.sh/uv/reference/settings/#no-build-package
Since our top-level settings differ from pip (we don't use :all:, we have a dedicated flag instead), I'm not sure how best to introduce environment variables for this.
I guess:
UV_NO_BINARY=1
UV_NO_BINARY_PACKAGE="foo bar"
And uv pip users would need to use the new syntax too?
Yeah, having environment variables available for this would be very useful for us. We have two different build environments we use, and neither of them make it particularly easy to add the --no-binary argument in the cases where we need it, but both make it really easy to add environment variables. I like @zanieb 's most recent suggestion for how to do it.
I'm happy to review a contribution adding the variables described.
I've added a version that handles build commands at https://github.com/astral-sh/uv/pull/11399.
Unfortunately, when doing so I noticed that the build commands and uv pip work somewhat differently, so I wanted to run my potential implementation up the flagpole before doing it.
The problem is that uv pip, like pip, has order-dependent instances of --no-binary and similar, and it does accept the special values of :all: and :none. My proposal therefore is to use a similar behaviour to how pip itself handles the environment variables, but to also handle the way uv pip handles them.
- If
UV_NO_BINARYis true,uv pipcommands treat that as equivalent touv pip <cmd> --no-binary=:all: [...]. - If
UV_NO_BINARY_PACKAGEis set,uv pipcommands treat that as equivalent touv pip <cmd> --no-binary=<package> [repeated for each unpacked package name] [...]
This is a special case only needed for pip commands because of how they work.
Yeah we'd reuse the top-level uv semantics in uv pip, that sounds correct.
Done in #11399
Oops, not done — not handled in uv pip yet.