astral-sh
Install and manage Python interpreters
uv venv accepts a --python flag that allows the user to specify a path to a particular Python interpreter or version if it is already installed on the machine. I would like for uv to install and manage Python for me, similar to conda create --name env-name python=3.9.
I am really enjoying using uv so far. Keep up the good work!
Consider the possibility to specify the required python version via a .python-version file within the project root dir, as suggested here: https://github.com/astral-sh/uv/issues/1850
I just want to chime in to say that I'm evaluating uv right now and my big question was whether and how it would handle installing Python itself. This is embarrassing, but I've been a Python developer for over a decade. I've used pip, virtualenvwrapper, Python 2 and 3, poetry, and more.
Whenever somebody tells me I have to use a specific version of Python, it sucks the life right out of me. I know there are tools for this. I know I use pip or poetry. I know I'm going to lose an hour figuring it all out, just like last time....
So, from my perspective, as a long-time Python dev, but an occasional installer of Python, I'd love to see this!
Thank you for the great tool. Impressive stuff.
We agree it's awfully painful to install and manage multiple Python versions across platforms. We'll be tackling this problem soon.
In terms of roadmap, is there any particular release that should have it or is it still the indeterminate future? I'd love to get rid of pyenv and need to set appropriate expectations 👀
It's next on my list of projects, following tool management (#3560) and rewriting interpreter discovery (#3266)
@zanieb It's been another half month, how's the progress going, is there a preview version?
Hi! There's now "preview" support for fetching and managing Python toolchains for you. I'll be working on documentation for the feature this week and there's quite a bit of work to be done before it's production-ready, but uv venv --preview --python <version> can now download missing versions for you.
You say "preview", I read "already in prod 😎". Jk, but I'm gonna use it on my personal box and see how it goes ❤️
@zanieb It's awesome, I tried it out, and everything works fine.
But I found it required py launch while using py --list-paths to find Python installations.
$ cargo run -q -- venv --python 3.10.11 --preview -v
warning: `C:\Users\Test\.cargo\config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
DEBUG Searching for Python 3.10.11 in search path, `py` launcher output, or managed toolchains
DEBUG Searching for managed toolchains at `C:\Users\Test\AppData\Roaming\uv\data\toolchains`
x The `py` launcher could not be found.
Is it possible to use a --standalone parameter to manage standalone Python downloads. And while using --standalone it won't using py --list-paths to find Python installtions. In this way, uv will create venv by using standalone Python without py launch.
@gotounix there's a UV_FORCE_MANAGED_PYTHON environment variable that, if set, ignores other interpreters but it's not tested and we'll be removing that in favor of whatever design we settle on in #4198 .
@gotounix there's a
UV_FORCE_MANAGED_PYTHONenvironment variable that, if set, ignores other interpreters but it's not tested and we'll be removing that in favor of whatever design we settle on in #4198 .
Is there a way to put the UV_FORCE_MANAGED_PYTHON environment variable in a configuration file so that it doesn't have to be entered every time?
0.2.22 version can use this command to create venv:
uv venv --python 3.10.11 --python-preference only-managed
We basically do this now, so I'm going to close this issue. We plan to add python shim support in the future.
This is super nice! One small point, the help is missing / incomplete for the venv part. I had to read here and try my best guess that I can actually do this line:
uv venv --python 3.12
I think this line is the best thing which has happened to the Python ecosystem in the last 10 years, please advertise it and put it in huge texts, it's amazing!
Thanks! There's https://docs.astral.sh/uv/guides/install-python/#viewing-python-installations maybe we could include it there. Ideally you just use uv run and don't even need to make a virtual environment yourself!
I'm always setting up a venv for every single one of my projects, and I think it's a best practice among Python devs. It's great to hear that I can get rid of pyenv + .python-version files with the new uv versions.
@hyperknot uv creates venvs automatically. I don't think any of the higher-level commands (the stuff released in 0.3.0, i.e. everything except uv pip and uv venv) work without one.
You can make a venv manually before running uv add, uv run, etc, but you don't need to - it gets created automatically.
Example:
> uv init
Initialized project `uv-test`
> uv add cowsay
Using Python 3.12.4
Creating virtualenv at: .venv
Resolved 2 packages in 213ms
Prepared 1 package in 25ms
Installed 1 package in 5ms
+ cowsay==6.1
> uv run python -m cowsay -t hello
_____
| hello |
=====
\
\
^__^
(oo)\_______
(__)\ )\/\
||----w |
|| ||
But I'm not getting something. I don't want to init and add, that's the easy part. I want a reproducible dev environment, which cleans up and sets everything up for me.
Here is the file I'm using in all my projects, I call this file with source or .. Every time I modify the dependencies, I just run it, it runs super fast, thanks to uv.
#!/usr/bin/env bash
find . -name "*.egg-info" -exec rm -rf {} +
find . -name __pycache__ -exec rm -rf {} +
find . -name .ipynb_checkpoints -exec rm -rf {} +
find . -name .pytest_cache -exec rm -rf {} +
find . -name .ruff_cache -exec rm -rf {} +
find . -name .DS_Store -exec rm -rf {} +
rm -rf .venv
uv venv
source .venv/bin/activate
uv pip -V
uv pip install -e .
cd js_tools
pnpm i
cd ..
+ I pair it with direnv so that it auto-activates when I'm inside the directory.
How would alternative uv commands help me in this?