Add support for respecting VIRTUAL_ENV in project commands via --active (#11189)

I think `UV_PROJECT_ENVIRONMENT` is too complicated for use-cases where
the user wants to sync to the active environment. I don't see a
compelling reason not to make opt-in easier. I see a lot of questions
about how to deal with this warning in the issue tracker, but it seems
painful to collect them here for posterity.

A notable behavior here — we'll treat this as equivalent to
`UV_PROJECT_ENVIRONMENT` so... if you point us to a valid virtual
environment that needs to be recreated for some reason (e.g., new Python
version request), we'll happily delete it and start over.
This commit is contained in:
Zanie Blue 2025-02-05 10:12:19 -06:00 committed by GitHub
parent 6f8d9b85d8
commit 989b103171
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
20 changed files with 368 additions and 33 deletions

View file

@ -190,8 +190,9 @@ To target this environment, you'd export `UV_PROJECT_ENVIRONMENT=/usr/local`.
!!! note
uv does not read the `VIRTUAL_ENV` environment variable during project operations. A warning
will be displayed if `VIRTUAL_ENV` is set to a different path than the project's environment.
By default, uv does not read the `VIRTUAL_ENV` environment variable during project operations.
A warning will be displayed if `VIRTUAL_ENV` is set to a different path than the project's
environment. The `--active` flag can be used to opt-in to respecting `VIRTUAL_ENV`.
## Limited resolution environments