mirror of
https://github.com/astral-sh/uv.git
synced 2025-08-04 19:08:04 +00:00
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:
parent
6f8d9b85d8
commit
989b103171
20 changed files with 368 additions and 33 deletions
|
@ -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
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue