For my use cases, uv is so frictionless it has effectively made Python tolerable for me. I primarily discovered it via Simon Willison's (@simonw) blog posts[1]. I recommend his blog highly.
Switching from Pyenv to Uv
71–80 of 239 posts
Re: Switching from Pyenv to Uv
#72Is there a guide for how to use uv if you're a JS dev coming from pnpm? I just want to create a monorepo with python that's purely for making libraries (no server / apps). And is it normal to have a venv for each library package you're building in a uv monorepo?
If the libraries are meant to be used together, you can get away with one venv. If they should be decoupled, then one venv per lib is better. There is not much to know: - uv python install if you want a particular version of python to be installed - uv init --vcs none [--python ] in each directory to initialize the python project - uv add [--dev] to add libraries to your venv - uv run when you want to run a command i…
Thanks. Why is the notion of run and tool separate? Coming from JS, we have the package.json#scripts field and everything executes via a `pnpm run ` command.
Re: Switching from Pyenv to Uv
#73I highly, highly recommend uv. It solves & installs dependencies incredibly fast, and the CLI is very intuitive once you've memorized a couple commands. It handles monorepos well with the "workspaces" concept, it can replace pipx with "uv tool install," handle building & publishing, and the docker image is great, you just add a FROM line to the top and copy the bin from /uv. I've used 'em all, pip + virtualenv, conda…
Adding dependencies to the script directly was a game-changer. I was able to write a script for a friend with no coding background at all and everything ran smoothly on his machine. No more rabbit holes of bundling Python packages and setting up environments!
Re: Switching from Pyenv to Uv
#74Are people seeing it work well in GPU/pydata land and creating multiplatform docker images? In the data science world, conda/mamba was needed because of this kind of thing, but a lot of room for improvement. We basically want lockfile, incremental+fast builds, and multi-arch for these tricky deps.
Works better than poetry for cuda-versioned pytorch. I don't have overlap with your other domains unfortunately (ML, not data science).
Re: Switching from Pyenv to Uv
#75This makes sense for people keen on pyenv.
I'm still very keen on virtualenvwrapper, I hope that the fast dependency resolution and install of uv can come there and to poetry.
Re: Switching from Pyenv to Uv
#76Maybe this one will finally be adopted as the official package manager for Python? Only 20 years late, but it would be a nice development.
Pfft. Pull the other one. The PSF hates the idea of dealing with something so icky. I have been pretty pleased with uv, but I am continually worried about the funding model. What happens when the VC starts demanding a return?
We fork it. Whatever carrot the VC's dangle can be chased by the handful who care, and the rest of us can continue using the important part.
Re: Switching from Pyenv to Uv
#77For scripting... HIGHLY recommend putting your dependencies inline. E.g.: #!/usr/bin/env python3 # /// script # requires-python = ">=3.11" # dependencies = [ # "psycopg2-binary", # "pyyaml", # ] # /// Then - uv run -s file.py
How does this interact with your code editor or IDE? When you edit the file, where does the editor look for information about the imported third-party libraries?
Re: Switching from Pyenv to Uv
#78Are people seeing it work well in GPU/pydata land and creating multiplatform docker images? In the data science world, conda/mamba was needed because of this kind of thing, but a lot of room for improvement. We basically want lockfile, incremental+fast builds, and multi-arch for these tricky deps.
It works transparently. The lock file is cross-platform by default. When using pytorch, it automatically installs with MPS support on macOS and CUDA on Linux; everything just works. I can't speak for Windows, though.
Re: Switching from Pyenv to Uv
#79The functionalities of three tooling projects, namely uv, ruff (linter), and pyright (type checker) need to merge and become mandatory for new Python projects. Together they will bring some limited sanity to Python.
Ruff is already integrated into uv and Astral are working on type checker.
How is ruff integrated? As far as I understand, it's still a separate tool that you need to install.
Re: Switching from Pyenv to Uv
#80I highly, highly recommend uv. It solves & installs dependencies incredibly fast, and the CLI is very intuitive once you've memorized a couple commands. It handles monorepos well with the "workspaces" concept, it can replace pipx with "uv tool install," handle building & publishing, and the docker image is great, you just add a FROM line to the top and copy the bin from /uv. I've used 'em all, pip + virtualenv, conda…
I generally agree but one thing I find very frustrating (i.e. have not figured out yet) is how deal with extras well, particularly with pytorch. Some of my machines have GPU, some don't and things like "uv add" end up uninstalling everything and installing the opposite forcing a resync with the appropriate --extra tag. The examples in the docs do things like CPU on windows and GPU on Linux but all my boxes are linux. There has to be a way to tell it that "hey I want --extra GPU" always on this box. But I haven't figured it out yet.