uv
uv copied to clipboard
astral-sh
Support custom virtual environment directory names
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?
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
@woutervh We don't want to scan every directory in your current directory on every invocation, so we use a heuristic.
@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
?
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 ...
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: https://github.com/astral-sh/uv/issues/1578.
from https://github.com/astral-sh/uv/issues/1495#issuecomment-1950793228
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
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.
See also:
- https://github.com/astral-sh/uv/issues/1396
- https://github.com/astral-sh/uv/issues/1632
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)