Support custom virtual environment directory names

[jkomalley]

It is common for virtual environment directories to be either .venv/ or venv/, but only .venv/ is currently supported in without needing to activate the environment. Since both are common names for virtual environments, could both be supported by default in uv? And/Or could there potentially be a config/environment variable that holds a user defined default virtual environment directory name that gets checked along with .venv/VIRTUAL_ENV/CONDA_PREFIX?

[woutervh]

I wonder why any hardcoding names are needed.
Just because a random folder is called ".venv" it is assumed a python virtualenv?

Why not checking on the presence of "pyvenv.cfg" + "bin" / "lib"-folders?

Why would this need to be different?

  > uv venv .venv
  > uv venv foo

[zanieb]

@woutervh We don't want to scan every directory in your current directory on every invocation, so we use a heuristic.

[woutervh]

@zanieb

how are you supposed to install a package when using a non-standard venv-name?
.venv is only used in an actual development-project.

uv venv foo
cd foo
?

[woutervh]

We don't want to scan every directory in your current directory on every invocation, .

That is a small performance-hit i'm very happy to endure,
compared to setting an environment every time you switch into a dozen directories.

the python-executable in a virtualenv is symlink to a global python,
yet it takes into account it's relative location to decide it is in a virtualenv and put its site-packages to its pythonpath.
if python can do that, why not uv?

I would love to see a uv-symlink in the venv's bin/ that only operates on the venv.

uv venv foo 
cd foo
bin/uv pip install ...

[wakamex]

pyenv-virtualenv solves this by identifying the env to be used in a folder in a .python-version file, which is then looked up automatically every time you enter a folder, and auto-activated. I'd love to see that behavior in uv, which I describe here: #1578.

[woutervh]

from #1495 (comment)

I have a solution for my use-case: symlink the foo-folder to a .venv-subfolder

uv venv foo
cd foo
ln -s . .venv
uv pip install <package>

@jkomalley this solves your use-case?

ln -s venv  .venv

[jkomalley]

Yes, that does work for my use case. Thanks!

I still think adding "venv/" to the venv search makes sense since (IMO) it's just as common as ".venv/", and both are listed as conventions in the venv documentation. The default one uv creates can be ".venv", but both should be expected by default since both are so common.

I think an option for venvs with other "non-default" names is to specify them in the pyproject.toml like this:

[tool.uv]
venvs = ["env1", "env2"]

Or, since multiple venvs potentially means different dependencies or python versions for each, maybe something like this:

[tool.uv.venvs.env1]
python="3.12"
deps=[
    "env1_dep1",
    "env1_dep2"
]

[tool.uv.venvs.env2]
python="3.10"
deps=[
    "env2_dep1",
    "env2_dep2"
]

For either, uv could then add "env1" and "env2" to the venv directory search.

When you make a new venv like uv venv foo, uv can add foo to pyproject.toml.

And when you run uv venv env1, and env1 doesn't exist, uv could create the venv and populate it with the env1 dependencies specified in pyproject.toml.

[zanieb]

See also:

• Flag to allow uv pip install to install into specific environments (that do not necessarily contain uv) #1396
• Create stub for uv in virtual environments #1632

[woutervh]

I have a solution for my use-case: symlink the foo-folder to a .venv-subfolder

uv venv foo
cd foo
ln -s . .venv
uv pip install

Unfortunately, I find myself in the situation to support windows-users.
Anno 2024 making symlinks on Windows is still PITA (Requires Powershell, administrator access, windows development mode)

[zanieb]

@woutervh I think you should be able to use a junction

[b-phi]

When running uv sync for a workspace, uv doesn't seem to respect VIRTUAL_ENV or an active virtual environment. The docs are pretty clear about this

uv.lock and .venv for the entire workspace are created next to this pyproject.toml.

In this case, being able to configure the name to use somewhere would be very helpful. Any of CLI parameters, pyproject.toml, envvar, etc would work for my use case.