Add environment variable to always use `--active` flag

[albireox]

Summary

The new --active flag (#11189) is a great addition and I think it goes some way to allow uv and pyenv to work better together (see #6204).

Would it be possible to add a new environment variable to make that flag the default? For example, the PR suggested something like UV_PROJECT_ENVIRONMENT=ACTIVE but could also be UV_ACTIVE=1. Or maybe this already works? If so, it's not clear from the documentation.

Example

No response

[zanieb]

I posted some ideas in #11189 (comment) but did not add one yet. I'm not sure what name is best.

[albireox]

I think any of the options in that comment would work. My personal preference would be a new variable, so something like UV_PROJECT_USE_ACTIVE.

[albireox]

Any updates on this?

[juditnovak]

May I give it a try (ore there's another volunteer already :-) )?

[oconnor663]

I'd like to get everyone's thoughts on @zanieb's questions from here: #13714 (comment)

• An environment variable here would apply equally to projects and scripts with inline metadata, is that what people would want? Or would you still expect a script to be run in a separate environment? Does that imply we want separate variables? Do we just want to tackle the UV_PROJECT_ENVIRONMENT case?
• How would this behave if VIRTUAL_ENV is not set? Would it error?

Now that I've read a bit more about pyenv[-virtualenv], I'm starting to worry that setting UV_[whatever]_ACTIVE=true in e.g. .bashrc (is that how folks would do it?) could create some other confusing interactions. Here are some scattered thoughts:

uv run does an "inexact" sync by default where it only adds dependencies to the environment, and doesn't remove anything. But uv sync does an "exact" sync by default, where it removes unneeded dependencies. Doing exact syncs in implicitly activated environments might break things in surprising ways, and editors and IDEs might do that for/to you automatically. (Inexact syncs can also break things by switching between incompatible versions of a package.)

The .python-version file that determines pyenv-virtualenv's "scope" might also be at a different level of the directory hierarchy than the pyproject.toml that uv looks for. ~/.python-version (do folks use those?) could interact with ~/foo/bar/baz/pyproject.toml, and foo/pyproject.toml could interact with foo/bar/baz/.python-version. Both of those might be unexpected?

At a high level, uv thinks it "owns" the environment it's working in. The --active flag sort of violates that assumption, but in a way that the user understands and intends. However, always violating that assumption seems like asking for trouble?

Could folks say more about the workflows they'd like to enable here? I wonder if there might be less footgun-y ways.

[samypr100]

Strictly personally I have historically used pyenv-virtualenv together with direnv using something like the layout activate <venv> pattern on a .envrc. Other times via the .python-version pyenv pattern.

Post uv-era, when I need to use centrally managed uv environments with the project api I still fundamentally use the same recipe with a few tweaks and ends up looking like:

export UV_PROJECT_ENVIRONMENT=$(pyenv root)/versions/<venv>
layout activate <venv>

For me at least having something like UV_PROJECT_ENVIRONMENT=VIRTUAL_ENV (or equivalent) would simplify this usage or recipes like this one by having to think less about where the environment lives when working on a uv project that uses a centralized managed environment.

Hence if something like UV_PROJECT_ENVIRONMENT=VIRTUAL_ENV ends up being supported,

• I would expect it to fail if there's no activated venv.
• I would not plan to permanently activate this environment variable, only when I'm on the valid uv project.