automatic uv venv activation/creation

[jdx]

Right now if someone wants to use mise with uv they could do this (I think anyhow, as someone that doesn't write python):

.python-version:

3.13.0

mise.toml:

[env]
_.python.venv = ".venv"

then they could run these commands:

$ uv venv # creates the venv
.. mise sets VIRTUAL_ENV/PATH based on the venv ..
$ uv add requests # I believe this creates pyproject.toml, if not that would be an extra step
$ python scripts/foo.py # called with uv's venv activated and `python` from the venv

I feel this is too many steps. I'm wondering if we could automate all of this. If we see there is a uv.lock file, we could automatically call uv venv to create the venv, and set VIRTUAL_ENV/PATH based on that new venv. Basically remove needing to put this into mise.toml and also not make the user manually create the venv.

cc @charliermarsh, would welcome any thoughts on how best to integrate with uv

[hverlin]

Sharing what I have seen (having recently tried it)

It's possible to use this to make mise create the venv automatically (through uv)

[tools]
python = 'latest'

[env]
_.python.venv = { path = ".venv", create = true } # create the venv if it doesn't exist

# mise automatically create the venv with uv
mise creating venv at: ~/Projects/test-python/.venv 
Using CPython 3.13.0 interpreter at: ~/.local/share/mise/installs/python/3.13.0/bin/python
...
uv init # create the pyproject.toml (would also have created the venv)
uv add requests
uv run hello.py

If I now delete the venv, I get the following output:

❯ rm -rf .venv
mise creating venv at: ~/Projects/test-python/.venv 
Using CPython 3.13.0 interpreter at: ~/.local/share/mise/installs/python/3.13.0/bin/python
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate

 ❯ uv run hello.py
Installed 5 packages in 24ms
Hello from test-python!

Note that uv run will also automatically create the venv if it's missing.
If I set _.python.venv = { path = ".venv", create = false }, here is the output:

❯ rm -rf .venv
mise WARN  no venv found at: ~/Projects/test-python/.venv                   

To create a virtualenv manually, run:
python -m venv ~/Projects/test-python/.venv

❯ uv run hello.py
Using CPython 3.13.0 interpreter at: /Users/hugues.verlin/.local/share/mise/installs/python/3.13.0/bin/python
Creating virtual environment at: .venv
Installed 5 packages in 12ms
Hello from test-python!

I think it works quite well already. Probably, mise could suggest adding the _.python.venv = { path = ".venv" ... } to mise.toml automatically if a uv project is detected.

[jdx]

I'm still thinking it would be good default behavior. I imagine if you're in a uv project you probably want to activate the venv.

[hverlin]

Agree, having a setting that does not require one to add the _.python.venv line would be great if it's turned on by default.

There are things where it might clash now, like the .python-version. If you set a different value that what mise is using, uv run will download the python defined in python-version (and install it in ~/.local/share/uv/python/<python-version>). This means that one should use .python-version to define the python version and not mise.toml.

There is also a UV_PROJECT_ENVIRONMENT environment variable, which might be set to something different from the venv in mise.toml. https://docs.astral.sh/uv/concepts/projects/config/#project-environment-path
A warning is printed when trying to use uv run in that case.

[jdx]

thinking about this more, I'm leaning towards not the default but having a setting like MISE_UV_VENV=1 that would enable this behavior.

There are things where it might clash now, like the .python-version. If you set a different value that what mise is using, uv run will download the python defined in python-version (and install it in ~/.local/share/uv/python/). This means that one should use .python-version to define the python version and not mise.toml.

It appears uv respects 2 env vars which are relevant here:

• UV_PYTHON - mise could set this if MISE_UV_VENV=1 in so you wouldn't need to use .python-version. I'm not sure if this deals with multiple pythons or not.
• VIRTUAL_ENV - uv claims to respect this env var, I would assume this means it uses the pythons from the venv and not .python-version but we'd need to verify this.

There is also a UV_PROJECT_ENVIRONMENT environment variable, which might be set to something different from the venv in mise.toml. https://docs.astral.sh/uv/concepts/projects/config/#project-environment-path
A warning is printed when trying to use uv run in that case.

We could probably read this if the integration is enabled, though I do know they also admonish not using .venv.

[hverlin]

VIRTUAL_ENV - uv claims to respect this env var

It does unless the venv does not exist already. You can try by deleting the venv, setting a different version of python in your mise.toml than in your .python-version and running uv run hello.py