Reconsider priority of CONDA_PREFIX when discovering virtual environments

[simonw]

Is the current treatment of CONDA_PREFIX definitely the right thing to do?

https://docs.astral.sh/uv/pip/environments/#discovery-of-python-environments

When running a command that mutates an environment such as uv pip sync or uv pip install, uv will search for a virtual environment in the following order:

• An activated virtual environment based on the VIRTUAL_ENV environment variable.
• An activated Conda environment based on the CONDA_PREFIX environment variable.
• A virtual environment at .venv in the current directory, or in the nearest parent directory.

Here's the problem: like many Python users (I imagine), while I don't actually use Conda I did end up with it on my system after one of many frustrating bouts of trying to use one machine learning library or another.

This means most of my shells now have that environment variable set.

As a result, uv was behaving very strangely for me. I made a bunch of notes in figuring this out here: https://gist.github.com/simonw/975dfa41e9b03bca2513a986d9aa3dcf

TLDR: Running uv pip install -e '.[test]' installed stuff in my global Conda environment and not my local .venv/ folder and I couldn't figure out why.

I doubt I'm the only person who has been confused by this. Is the current behavior an irreversible decision at this point?

[zanieb]

Hey @simonw — did you try 0.5.0? We actually just special-cased the "base" Conda environment #7691

[simonw]

Yes - I can confirm this is fixed in 0.5!

Here's my experiment to prove it - I tried uv 0.4 and the package was installed in the Conda environment, but under 0.5 the same thing put it in .venv instead:

$ pip install 'uv<0.5' 
Collecting uv<0.5
  Downloading uv-0.4.30-py3-none-macosx_11_0_arm64.whl.metadata (11 kB)
Downloading uv-0.4.30-py3-none-macosx_11_0_arm64.whl (12.5 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 12.5/12.5 MB 22.2 MB/s eta 0:00:00
Installing collected packages: uv
  Attempting uninstall: uv
    Found existing installation: uv 0.5.0
    Uninstalling uv-0.5.0:
      Successfully uninstalled uv-0.5.0
Successfully installed uv-0.4.30
$ uv --version
uv 0.4.30 (61ed2a236 2024-11-04)
$ mkdir /tmp/uv4
$ cd /tmp/uv4
$ uv venv
Using CPython 3.11.1
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
$ uv pip install cowsay
Using Python 3.10.10 environment at /opt/homebrew/Caskroom/miniconda/base
Resolved 1 package in 96ms
Installed 1 package in 3ms
 + cowsay==6.1
$ uv run which cowsay
/opt/homebrew/Caskroom/miniconda/base/bin/cowsay
$ mkdir /tmp/uv5
$ cd /tmp/uv5
$ pip install 'uv>=0.5'
Collecting uv>=0.5
  Using cached uv-0.5.0-py3-none-macosx_11_0_arm64.whl.metadata (11 kB)
Using cached uv-0.5.0-py3-none-macosx_11_0_arm64.whl (12.5 MB)
Installing collected packages: uv
  Attempting uninstall: uv
    Found existing installation: uv 0.4.30
    Uninstalling uv-0.4.30:
      Successfully uninstalled uv-0.4.30
Successfully installed uv-0.5.0
$ uv venv
Using CPython 3.10.10 interpreter at: /opt/homebrew/Caskroom/miniconda/base/bin/python3
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
$ uv pip install cowsay
Resolved 1 package in 2ms
Installed 1 package in 2ms
 + cowsay==6.1
$ uv run which cowsay
/private/tmp/uv5/.venv/bin/cowsay

[simonw]

Turns out this issue was a dupe of:

• Enhancement: Change order of discovery of python environments for uv pip install  #7124

[charliermarsh]

Great timing :D