Use uv for much faster Python virtual env creation

[rsyring]

virtualenv and uv venv are much faster than python -m venv at creating virtual envs:

❯ time python -m venv python-demo           # 2.79 secs

❯ time pyvenv/bin/virtualenv venv-demo     #  224.15 millis

❯ time pyvenv/bin/uv venv uv-venv-demo  # 19.79 millis

I'm not sure how best to ensure those tools are installed and can be used. Should mise offer an "install command" type option (like tox) or just use uv or virtualenv if its on the path and assume the user is taking care of that? I'm inclined towards the latter and, if a user wants it to be more automatic, they should put their desired tool in default-python-packages or, as I would do, make it available using pipx.

[nickchomey]

If this doesn't happen, you might consider using Rye, which is now developed by the same folks as uv and uses it under the hood. Their goal is to make the Rust cargo of python.

I wrote about how I got it working in mise here - you can just skip the mise python altogether. You might even say it is the mise of python!

[keybits]

The 0.3 release of Uv incorporates much of the functionality of Rye (and the author of Rye is hoping for a future where Uv makes Rye redundant). (Mandatory mention: uV is written in Rust 😉 )

If Uv is becoming the best way to manage all things Python, it could be good for mise to make Uv the default approach as suggested above and add documentation to that effect.

[HipsterBrown]

Given the recent experiments with alternative "backends", it would be interesting to make one for uv as a first step.

[jdx]

this should be pretty easy to do if someone wants to take it on, just add code here to use uv if it's on PATH:

mise/src/config/env_directive.rs

Lines 178 to 184 in ba90c3b

	let cmd = CmdLineRunner::new("python3")
	.args(["-m", "venv", &venv.to_string_lossy()])
	.envs(&env_vars)
	.env(
	PATH_KEY.to_string(),
	env::join_paths(&path)?.to_string_lossy().to_string(),
	);

Also put it behind a setting so people can opt-out.