uv add and uv sync doesn't install packages in virtual env created by uv venv <custom venv name> but creates the default .venv

[amanchaudhary-95]

Current uv version: uv 0.4.29 (85f9a0d 2024-10-30)
OS: Windows 11

I created a project using uv init and then created a venv with the name "Temp_Venv" inside that project using uv venv Temp_Venv, the environment was created perfectly. After that, I activated the newly created environment and tried to add python package using uv add pandas, it did not install the package in the activated environment instead it created a new environment with the name .venv and installed the package in that environment. It does the same even after setting the VIRTUAL_ENV=D:\Test\Test_Venv\Temp_Venv.

Steps to reproduce:

Step 1: Init a Project with uv init Test_Venv

Step 2: Change the directory and create a venv with a custom name of 'Temp_Venv' in that project
cd .\Test_Venv\
uv venv Temp_Venv

Step 3: Activate the newly created venv
.\Temp_Venv\Scripts\activate

Step 4: Add a package using uv add
uv add pandas

It will give a warning
warning: `VIRTUAL_ENV=Temp_Venv` does not match the project environment path `.venv` and will be ignored
and it will create a new venv with a default name .venv and it will add the package in this .venv env and not in the activated Temp_Venv

I also tried to set the VIRTUAL_ENV path but still got the same result

Screenshot:

[nlohmann]

Same issue when using

uv venv venv
source venv/bin/activate
uv sync

Output of the last command:

warning: `VIRTUAL_ENV=venv` does not match the project environment path `.venv` and will be ignored
Using CPython 3.13.0 interpreter at: /opt/homebrew/opt/python@3.13/bin/python3.13
Creating virtual environment at: .venv

[berislavlopac]

The documentation says that uv does not respect the VIRTUAL_ENV variable, which I find very annoying; see https://docs.astral.sh/uv/concepts/projects/#configuring-the-project-environment-path

[charliermarsh]

The top-level project commands (uv sync, uv lock, uv run, uv tree, uv export) always use .venv. It's intentional and that's why you're seeing a warning to make you aware of the behavior. You can set UV_PROJECT_ENVIRONMENT to use something else, though it's largely intended for use in continuous integration and other environments.

[nlohmann]

I see. It might be intentional, but it's currently blocking the adoption of uv in a project, because all existing documentation and CI pipelines assume venv to be the path, and changing all this to .venv is too much effort. Maybe on top of the warning, a parameter to override this behavior could be helpful.

In the meantime, is there a way to set the project environment in pyproject.toml?

[charliermarsh]

No, we don't expose it in the pyproject.toml though I'll let @zanieb comment on whether we'd add that. We're intentionally pushing to standardize on this naming scheme in these new APIs. (The uv pip APIs work with other environments without an issue.)

[berislavlopac]

@charliermarsh I'm curious why was it decided not to honour that variable? It's a pretty standard solution, and it's a common practice to manage the environment separately from the packaging and dependency management.

[charliermarsh]

We honor it in uv pip but not the project APIs, which is based around a more opinionated workflow. There's context on it here: #6834.

[berislavlopac]

OK, fair enough, I understand the decision. I'm not sure yet whether I agree with it, but I'll try playing with uv without an active environment and decide based on how much that affects my workflow (having to put uv run in front of every command is a bit annoying and goes against my muscle memory, but I can think of a few workarounds).

The only other thing I can think of might be to include a configuration option to prevent running a command if there is an activated environment (or at least to add a confirmation prompt, instead of just a warning); I'd prefer to have some control when an environment is created.

[zanieb]

No, we don't expose it in the pyproject.toml though I'll let @zanieb comment on whether we'd add that.

No we're not planning on adding it to the pyproject.toml; I don't think the project should be able to declare where the developer stores the virtual environment. We might add support in the uv.toml though.

all existing documentation and CI pipelines assume venv to be the path

Why does the virtual environment need to be discoverable at a hard-coded path? Just want to try to understand the use-case.

I'll try playing with uv without an active environment and decide based on how much that affects my workflow (having to put uv run in front of every command is a bit annoying and goes against my muscle memory, but I can think of a few workarounds).

You can definitely activate the environment still.

and changing all this to .venv is too much effort.

Does UV_PROJECT_ENVIRONMENT not work for you?

[berislavlopac]

You can definitely activate the environment still.

Oh, of course; it's just that in my case a couple of uv's idiosyncracies collide with my usual setup. But as I said, I can think of a few workarounds; I'll know more when I try them.

[amanchaudhary-95]

No, we don't expose it in the pyproject.toml though I'll let @zanieb comment on whether we'd add that.

No we're not planning on adding it to the pyproject.toml; I don't think the project should be able to declare where the developer stores the virtual environment. We might add support in the uv.toml though.

all existing documentation and CI pipelines assume venv to be the path

Why does the virtual environment need to be discoverable at a hard-coded path? Just want to try to understand the use-case.

I'll try playing with uv without an active environment and decide based on how much that affects my workflow (having to put uv run in front of every command is a bit annoying and goes against my muscle memory, but I can think of a few workarounds).

You can definitely activate the environment still.

and changing all this to .venv is too much effort.

Does UV_PROJECT_ENVIRONMENT not work for you?

Hi @zanieb, I also tried setting the UV_PROJECT_ENVIRONMENT variable as an absolute path as set UV_PROJECT_ENVIRONMENT=D:\Test\Test_Venv\Temp_Venv and as relative path as set UV_PROJECT_ENVIRONMENT=Temp_Venv but I'm still getting the same warning. Packages are added in the autocreated .venv environment

[nlohmann]

all existing documentation and CI pipelines assume venv to be the path

Why does the virtual environment need to be discoverable at a hard-coded path? Just want to try to understand the use-case.

We have a very heavy Makefile that has targets for a lot of jobs such as creating a virtual environment, execute tests, etc. That Makefile predates tools like uv and is used in multiple projects to unify the workflows. As such venv is hardcoded there and then also assumed as path in the CI jobs. This is not nice and I want to modernize this with tools like uv. For this, I don't want to touch too much, and it would be much easier for me to just keep the virtual environment at venv.

and changing all this to .venv is too much effort.

Does UV_PROJECT_ENVIRONMENT not work for you?

I don't control the developers environment variables, so I cannot assume that variable to be set. I can try to pull it into our Makefile, but rooting this to pyproject.toml would have been the easier choice.

[reder2000]

It is also really annoying because I cannot use uv add with pycharm or with different Python versions.

[thomasaarholt]

@amanchaudhary-95 I get it to work by setting the UV_PROJECT_ENVIRONMENT env variable equal to the VIRTUAL_ENV. The important point is that UV_PROJECT_ENVIRONMENT needs to be a full path, or I guess relative to the current directory (as .venv would be).

[reder2000]

pycharm just added official support for uv and it sucks because there is no way to choose where files are installed. (Poetry support sucks as well, but a bit differently)

[zanieb]

We now support a --active flag on uv sync, uv run, etc.

(But we won't detect inactive environments with arbitrary names and won't detect active environments by default. See #11273 for a non-CLI option)