Unable to activate VIRTUAL_ENV when CONDA_PREFIX exists

[YuShigurey]

I'm trying out uv, together with hatch-pip-compile (and hatch). venv creation works fine, and speed is significantly faster, great!

Except when I try to run command with created virtual env, error raises

(base)  test-hatch-pip-compile$ hatch run default1:python
error: Both VIRTUAL_ENV and CONDA_PREFIX are set. Please unset one of them.

The error message is clean, that's great, and I can fix it on my computer in 5 seconds (conda deactivate).
I just wonder if there is any difficulty makes this "user action" necessary?

Here is the hatch.toml (very likely unrelated imo since hatch is just an invoker and after I deactivated conda environment everything looks ok)

[env]
requires = [
    "hatch-pip-compile",
]

[envs.default]
path = ".venv/default"

[envs.default1]
path = ".venv/default1"
type = "pip-compile"
pip-compile-installer = "uv"
pip-compile-resolver = "uv"

Thank you!

[charliermarsh]

@konstin - Thoughts?

[konstin]

We could have VIRTUAL_ENV take precedence over CONDA_PREFIX if the python in PATH is from that venv; I'm not sure what behavior conda users would expect.

[ananis25]

We could have VIRTUAL_ENV take precedence over CONDA_PREFIX if the python in PATH is from that venv; I'm not sure what behavior conda users would expect.

This'd be useful, same error came up when using Rye to set up a new project, while the global python comes from Conda.
Having a base conda/mamba env activated is useful for one-off scripts (Rye is a bit new to use everywhere).

[matthewfeickert]

This also happens if you try to have uv be installed globally with pixi via pixi global install uv.

The easy alternative is just to globally install uv itself, but it is nice to have pixi global be able to manage all your tools with a pixi global upgrade-all.

[notatallshaw]

We could have VIRTUAL_ENV take precedence over CONDA_PREFIX if the python in PATH is from that venv; I'm not sure what behavior conda users would expect.

When conda is activated it can be considered a globally available Python, therefore when a virtual environment is activated in a conda environment it is equivalent to a virtual environment being activated when there is a system install, the virtual environment should take precedence.

This has come up a few of times on pip issues, I'll try and find the discussion .

But anecdotally when I was a heavy conda user this is what I would have expected.