Support flags via environment variables

[gaborbernat]

Pip supports setting environment variables via flags, today I know of UV_INDEX_URL and UV_EXTRA_INDEX_URL that uv also has.

However, such as PIP_PREFER_BINARY=true I don't think has an equivalent. It would be nice if uv would do similar for all flags in case.

[zanieb]

I think it's unlikely that we try to match all of the pip environment variables — we've tried to avoid environment based configuration in Ruff (for reasons unknown to me, I kind of like having a variable for each option). Is there a particular reason this would be useful?

[gaborbernat]

Because you can control the indexes via UV_INDEX_URL and UV_EXTRA_INDEX_URL; but if both have a package currently the first one will take priority, and there's no way without this to tell, prioritize the index that has a wheel...

[charliermarsh]

I don't mind adding environment variable support, personally. (But I'd prefer to have our own UV_* variables rather than read PIP_* variables.)

[gaborbernat]

I agree with not reusing pip ones 🧐

[mgaitan]

running uv --help I can see there is some flags that supports envvars, like

      --cache-dir <CACHE_DIR>
          Path to the cache directory
          
          [env: UV_CACHE_DIR=]

but others doesn't like --color or --verbose . Couldn't be the support for environment variable generalized with the same UV_<UPPER_CLI_FLAG> pattern?

[Czaki]

@zanieb @charliermarsh I may be interested to implementing this (it is blocking me to migrate test to use uv). Where is the best place to ask some questions (if I am good, understanding code structure for example)?

[charliermarsh]

@Czaki -- You're welcome to either (1) ask questions here, (2) open a draft PR early and ask questions there, or (3) ask in Discord. I have a minor preference for fielding questions in GitHub but it's whatever you prefer!

I suspect the changes would mostly be in: https://github.com/astral-sh/uv/blob/14d968ac224c88988c60b6c067f0cafbc3ea4a07/crates/uv/src/main.rs#L475.

(Not sure if @zanieb has objections to adding these, maybe wait for Zanie to chime in.)

[zanieb]

We can add these but we might want to scope some of the more specific options e.g.ONLY_BINARY to UV_PIP_ instead of UV_.

Edit: I said this same thing longer at https://github.com/astral-sh/uv/issues/1535#issuecomment-1960718966

[mimre25]

Not sure if this is the right place, but I stumbled upon PIP_CONSTRAINT for build constraints missing.

I've tried UV_CONSTRAINT, but that doesn't seem to be accounted for either.

Is there currently a way to set this?

[Czaki]

@mimre25 only using flags. This Issue is about introducing such an option.

[mimre25]

:facepalm: why didn't I think of that?

Anyhow, to offer something to the discussion:

The premise first premises of uv states:

An extremely fast Python package installer and resolver, written in Rust. Designed as a drop-in replacement for pip and pip-compile.

(Highlight by me).

Wouldn't it make sense to use the PIP_* environment variable in this case? Otherwise, uv won't be a drop-in replacement for pip anymore.

[Czaki]

I agree that this statement is not true, and based on other issues it will never be true.

[charliermarsh]

I'd like to support more environment variables for uv, but reading configuration files and environment variables intended for other tools isn't a sustainable strategy. It means we need to be bug-for-bug compatible with those other tools, since users will end up relying on bugs in the format, the parser, etc.; and if the other tool changes the format in some way, we're then locked in to changing it in parallel ways to avoid breaking things for users. If that configuration is versioned in some way, it gets even harder, since we might need to know which version of the other tool you're expecting to use. It also means that we cannot introduce any of our settings or configuration, since otherwise our pip.conf (if we, for example, used that configuration file) would no longer be useable with pip. Conversely, it can also lead to a lot of user confusion -- if we read configuration files intended for other tools, I'm certain we'd receive issues in which users were surprised that we did read those files, since they're not intended for us.

We plan to have our own environment variables and our own persistent configuration format. We'll document these differences in our pip compatibility policy (https://github.com/astral-sh/uv/issues/2023).

[tafia]

I think I understand where you're coming from but pip.conf is a de-facto standard. I don't remember ever changing it so I'd say it is particularly stable and deserves an exception.

[zanieb]

It's really important to distinguish between de-facto standards established by tools and actual standards though. We're very interested in improving the standards such that there is not a tool-specific file that every other tool needs to deal with.

[pawamoy]

Sorry if this is the wrong place: could uv support a UV_RESOLUTION environment variable, with possible values highest, lowest, lowest-direct? It's not critical, I can easily check this env var and set the according CLI flag myself :slightly_smiling_face:

if [ -n "${UV_RESOLUTION}" ]; then
  uv_opts="--resolution=${UV_RESOLUTION}"
fi

[charliermarsh]

Happy to add -- do you mind creating a separate issue just for tracking?

[charliermarsh]

Closing for now as we have many of these.