That single command creates a throwaway virtual environment, installs an alpha release of my LLM tool, adds an alpha release of my llm-claude-3 plugin, runs that command with options, returns the results and then throws everything away again.
And because of the way uv uses symlinks and caching, running the commands a second time is almost instant.
I have no relation with the Astral team but have been an early and aggressive adopter of everything they've released and it's all been easy, fast, and ergonomic. Over the past eighteen months I've:
1. Replaced `flake8` with `ruff`;
2. Replaced `black` with `ruff`;
3. Replaced `pip` with `uv`;
4. Replaced `poetry` with `uv`.
Their next project appears to be exactly what I _wish_ their next project to be — a replacement for pyright et al (https://github.com/astral-sh/ruff/discussions/10581). Type checking is my least favorite part of my Python toolchain at the moment; I can't wait to take it for a spin.
they are working on it! the internal name is currently red-knot (you can see it in their GH History and in the discord). First thing is a type checker, I think, then the renaming capabilities and such.
In addition to what everybody else has mentioned, uv plays nice with other people's build tools. I use scikit-build-core for building most of my python packages and making scikit-build-core play nicely with poetry was somewhere between very hard and impossible. UV trivially lets me combine the two so I can let uv do what it does best (manage and install python versions and dependencies) and then have it get out of the way and let scikit-build-core take over and do what it does best.
uv also manages the Python version as well, and it doesn't require jumping through hoops and hacking to get it to play nicely with Docker. uv is much more of a production-ready setup than pip or poetry from my experience moving to uv over the last few weeks
Astral's tools (Ruff, uv) are awesome, I'm a big fan. I'm using them every time I can and recommending them everywhere. I use them for my open source projects (FastAPI, Typer, SQLModel, etc.) and also for private things, small and big, even small scripts, everything. Also, they have great docs, and I'm kinda picky with docs. I'm looking forward to whatever they build next, I'm pretty sure I'll like it. By now, it's not just by chance that they built one great thing, it's a trend, they build great stuff.
Ruff is great because you need to lint your code all the time and you could save maybe 1 minute per CI.
As for Python package management, my team is migrating to Bazel which has its own way of locking in the Python dependencies and then pulling them from a remote cache. Under Bazel, we are only re-examining the dependencies when someone proposes a change to produce the lock. It's so rare, that having a new+faster thing that does this part would not present a meaningful benefit.
ruff has been a fantastic discovery for me, along with pre-commit, commitizen, and flit.
In about the length of a weekend I was able to find a reasonable group of settings for my pyproject.toml and roll that out to many of my projects.
The tooling is maturing and converging on more common ground (eg pyproject.toml) while adopting existing, accepted practices and standards.
The documentation is awesome and integrates well within my IDE of choice (pycharm)
Myself, I run ruff with most of the lintiners turned on. It is quite strict and opinionated (to the point of pedantic) -- a good learning path for me because I would never read PEPs anyway.
But once it is running I just stay within bounds and take the enforced rigor around doc-strings, syntatic sugar, and other little things.
I'm not on the uv train yet because I have no issues with venv and pip right now.
For now their decisions align with the community needs and everyone is happy.
But what will gonna be when their investors needs divert from the community needs or worse, they fail to meet their investors financial expectations and shutdown?
Coming from the Poetry world, I'm loving ruff and uv. It's awesome having one single binary to handle linting for both convention and format, and uv itself is amazingly fast.
I do miss being able to shell into an env, but it hasn't been a big deal because you can still run `uv run -- code .` to launch VSCode with the right Python interpreter.
It's surprising to me that the future toolchain for Python productivity is Rust, but the results are awesome.
Just fyi since UV generates a virtual environment in .venv you can just point to the .venv folder in VSCode and stuff should work
(I highly recommend using direnv and sourcing the virtual environment in a .envrc file though… when your editor has support for that it works so well compared to bespoke shell tools)
I was actually thinking of creating a python-pipx but for uv instead in archlinux (because arch has some workarounds to do with in pip , you can't just do pip install something , you need to do it with pacman)
I really hope that any developer is reading this and is interested in this project , they do this. because I don't feel like doing it but I honestly feel its impact because I wanted to try nomadnet once on arch machine and I tried pipx and it was so slow
> Tool management: `uv tool install` and `uv tool` run (aliased to uvx). uv can now install command-line tools in isolated virtual environments and execute one-off commands without explicit installation (e.g., `uvx ruff check`), making it a high-performance, unified alternative to tools like pipx.
Problem: python is very hard to use consistently across various environments
Solution: make python execution as disposable as paper plates :)
Uv works very well for me, but it does still sometimes run into weird issues when the underlying python installation is bad (ie installing a library that depends on a dev build)
Really enjoy using pdm. Might make the move when there’s more maturity on uv, but for now it does the job and I just switched from pipenv to pdm. Too many changes too often.
When I would be excited for is an actual LSP alternative to pylance. Pylance is basically a proprietary monopoly. Kind of crazy for Python to not have its own high performance LSP.
The speed of uv relative to other dependency management tools I've tried is incredible. My biggest hangup so far is that there isn't as great support for automated dependency updates as with more mature tools.
Seems like the only ecosystem that moves as fast and is as fragmented as JavaScript is Python, so I'll wait before jumping on the hype train. Looks interesting though.
I've migrated a couple moderately large projects from pyenv & poetry to uv, and it has been great. The switch was easier than I expected. I uninstalled pyenv after a few weeks, as I realized that uv makes it irrelevant. I've also replaced pipx (which manages Python tools/programs each with their own virtual environment) with uv's tool feature. I used uv for every new Python project. The only thing it's missing that's important for me is support by Dependabot on GitHub. Once Dependabot can update its lock files, I'll be able to uninstall poetry.
I had some trouble migrating from Poetry to uv because the dependency constraints are different. With Poetry, you can use caret ^ and tilde ~ version constraints. Apparently this is outside the PEP spec so uv doesn't implement it. Understandable, but it does make the migration a bit troublesome at times.
That’s a great combination that I’ve been using up until very recently. If you have it up and running, I don’t see huge benefits in switching to uv today.
In contrast, I had to use pipenv recently and I’d forgotten how terrible its UX was. I wanted to upgrade one of the deps in a smallish project and it took 43 seconds to resolve the change. If anyone reading this is using pipenv, switch to uv right now and thank me later.
That used to be my stack, I’ve found that asdf and poetry fit me better (I dreaded having to set up pyenv and/or it working some of the time). The time saver has also been that I no longer have to keep any other language’s bespoke language version environment switcher in my head as much (goodbye nvm too)
Did you see the performance gains? Even in marginal case (with caching) 4.6s => 0.15s resolution (compared to poetry). Even better when there are cache misses
Respectfully, your dogmatism doesn't seem to serve you with numbers like that
The more tricks I learn with uv the more I like it.
The other day I got to share a demo by pasting this command in a Discord channel:
That single command creates a throwaway virtual environment, installs an alpha release of my LLM tool, adds an alpha release of my llm-claude-3 plugin, runs that command with options, returns the results and then throws everything away again.And because of the way uv uses symlinks and caching, running the commands a second time is almost instant.
(That stuff is no longer alpha, see https://simonwillison.net/2024/Oct/29/llm-multi-modal/)
I have no relation with the Astral team but have been an early and aggressive adopter of everything they've released and it's all been easy, fast, and ergonomic. Over the past eighteen months I've:
1. Replaced `flake8` with `ruff`;
2. Replaced `black` with `ruff`;
3. Replaced `pip` with `uv`;
4. Replaced `poetry` with `uv`.
Their next project appears to be exactly what I _wish_ their next project to be — a replacement for pyright et al (https://github.com/astral-sh/ruff/discussions/10581). Type checking is my least favorite part of my Python toolchain at the moment; I can't wait to take it for a spin.
Pyright was itself a big improvement over Mypy. Just look at this for starters: https://htmlpreview.github.io/?https://github.com/python/typ...
If Astral can leapfrog Pyright too, great. But I think it will be significantly harder than leapfrogging Flake8 and Black was.
Pylance is nicer than pyright, but unfortunately I don't think you can use it outside of vs code
It's not clear to me that they are building an alternate type checker per se
Seems like `ruff server` is an LSP?
Yes but only for linting (the flake8 rules etc). The end goal is to have proper type checking and, I think, proper LSP refactoring capabilities.
they are working on it! the internal name is currently red-knot (you can see it in their GH History and in the discord). First thing is a type checker, I think, then the renaming capabilities and such.
What benefits does uv have over poetry?
In addition to what everybody else has mentioned, uv plays nice with other people's build tools. I use scikit-build-core for building most of my python packages and making scikit-build-core play nicely with poetry was somewhere between very hard and impossible. UV trivially lets me combine the two so I can let uv do what it does best (manage and install python versions and dependencies) and then have it get out of the way and let scikit-build-core take over and do what it does best.
Speed, compatibility, ergonomics, standards compliance.
also a whole bunch of new features (--script mode), speed of development, a stacked team.
uv also manages the Python version as well, and it doesn't require jumping through hoops and hacking to get it to play nicely with Docker. uv is much more of a production-ready setup than pip or poetry from my experience moving to uv over the last few weeks
Works with pytorch.
Astral's tools (Ruff, uv) are awesome, I'm a big fan. I'm using them every time I can and recommending them everywhere. I use them for my open source projects (FastAPI, Typer, SQLModel, etc.) and also for private things, small and big, even small scripts, everything. Also, they have great docs, and I'm kinda picky with docs. I'm looking forward to whatever they build next, I'm pretty sure I'll like it. By now, it's not just by chance that they built one great thing, it's a trend, they build great stuff.
In my experience:
Ruff is great because you need to lint your code all the time and you could save maybe 1 minute per CI.
As for Python package management, my team is migrating to Bazel which has its own way of locking in the Python dependencies and then pulling them from a remote cache. Under Bazel, we are only re-examining the dependencies when someone proposes a change to produce the lock. It's so rare, that having a new+faster thing that does this part would not present a meaningful benefit.
ruff has been a fantastic discovery for me, along with pre-commit, commitizen, and flit.
In about the length of a weekend I was able to find a reasonable group of settings for my pyproject.toml and roll that out to many of my projects.
The tooling is maturing and converging on more common ground (eg pyproject.toml) while adopting existing, accepted practices and standards.
The documentation is awesome and integrates well within my IDE of choice (pycharm)
Myself, I run ruff with most of the lintiners turned on. It is quite strict and opinionated (to the point of pedantic) -- a good learning path for me because I would never read PEPs anyway.
But once it is running I just stay within bounds and take the enforced rigor around doc-strings, syntatic sugar, and other little things.
I'm not on the uv train yet because I have no issues with venv and pip right now.
Astral is a VC baked company.
For now their decisions align with the community needs and everyone is happy.
But what will gonna be when their investors needs divert from the community needs or worse, they fail to meet their investors financial expectations and shutdown?
Then you'll have a very good, open-source, MIT licensed tool financed by silly VCs.
If it gets abandoned the community will be able to take over its maintenance or fork you.
Tails, you win, heads, you win.
https://github.com/astral-sh/ruff/blob/main/LICENSE
Coming from the Poetry world, I'm loving ruff and uv. It's awesome having one single binary to handle linting for both convention and format, and uv itself is amazingly fast.
I do miss being able to shell into an env, but it hasn't been a big deal because you can still run `uv run -- code .` to launch VSCode with the right Python interpreter.
It's surprising to me that the future toolchain for Python productivity is Rust, but the results are awesome.
Just fyi since UV generates a virtual environment in .venv you can just point to the .venv folder in VSCode and stuff should work
(I highly recommend using direnv and sourcing the virtual environment in a .envrc file though… when your editor has support for that it works so well compared to bespoke shell tools)
I was actually thinking of creating a python-pipx but for uv instead in archlinux (because arch has some workarounds to do with in pip , you can't just do pip install something , you need to do it with pacman)
I really hope that any developer is reading this and is interested in this project , they do this. because I don't feel like doing it but I honestly feel its impact because I wanted to try nomadnet once on arch machine and I tried pipx and it was so slow
Does `uv tool` fit the bill? https://docs.astral.sh/uv/concepts/tools/
From https://astral.sh/blog/uv-unified-python-packaging
> Tool management: `uv tool install` and `uv tool` run (aliased to uvx). uv can now install command-line tools in isolated virtual environments and execute one-off commands without explicit installation (e.g., `uvx ruff check`), making it a high-performance, unified alternative to tools like pipx.
I'm not super familiar with archlinux but maybe `uvx` or `uv run` already do parts of what you want?
https://docs.astral.sh/uv/guides/tools/
https://docs.astral.sh/uv/guides/scripts/
Problem: python is very hard to use consistently across various environments
Solution: make python execution as disposable as paper plates :)
Uv works very well for me, but it does still sometimes run into weird issues when the underlying python installation is bad (ie installing a library that depends on a dev build)
Ive moved all my flows to uv but still use venv and pip install -r for quick things.
Me too. I use uv for python installation management and just vanilla pip and venv to run python projects.
Why are we posting this now? I think uv, ruff, and astral have been posted here so often. Is something new here that I am missing?
FWIW I’ve never heard of these tools until today
Really enjoy using pdm. Might make the move when there’s more maturity on uv, but for now it does the job and I just switched from pipenv to pdm. Too many changes too often.
When I would be excited for is an actual LSP alternative to pylance. Pylance is basically a proprietary monopoly. Kind of crazy for Python to not have its own high performance LSP.
The speed of uv relative to other dependency management tools I've tried is incredible. My biggest hangup so far is that there isn't as great support for automated dependency updates as with more mature tools.
Seems like the only ecosystem that moves as fast and is as fragmented as JavaScript is Python, so I'll wait before jumping on the hype train. Looks interesting though.
Started with rye first, but now fully turned to uv.
Such a breeze to work with.
Right now we're still all-in on pyenv & poetry.. I need to evaluate where this is at in comparison
I have also settled for pyenv and poetry. It works fine so far. If you evaluate Astral, please let me know.
I've migrated a couple moderately large projects from pyenv & poetry to uv, and it has been great. The switch was easier than I expected. I uninstalled pyenv after a few weeks, as I realized that uv makes it irrelevant. I've also replaced pipx (which manages Python tools/programs each with their own virtual environment) with uv's tool feature. I used uv for every new Python project. The only thing it's missing that's important for me is support by Dependabot on GitHub. Once Dependabot can update its lock files, I'll be able to uninstall poetry.
I had some trouble migrating from Poetry to uv because the dependency constraints are different. With Poetry, you can use caret ^ and tilde ~ version constraints. Apparently this is outside the PEP spec so uv doesn't implement it. Understandable, but it does make the migration a bit troublesome at times.
That’s a great combination that I’ve been using up until very recently. If you have it up and running, I don’t see huge benefits in switching to uv today.
In contrast, I had to use pipenv recently and I’d forgotten how terrible its UX was. I wanted to upgrade one of the deps in a smallish project and it took 43 seconds to resolve the change. If anyone reading this is using pipenv, switch to uv right now and thank me later.
That used to be my stack, I’ve found that asdf and poetry fit me better (I dreaded having to set up pyenv and/or it working some of the time). The time saver has also been that I no longer have to keep any other language’s bespoke language version environment switcher in my head as much (goodbye nvm too)
I've used `uv` a bunch. It was really, really good but didn't cover our use cases. I think that's probably changed now. Ruff also looks pretty cool.
You had me with the linter, but you lost me with the package manager.
Yet another package manager is not what Python needs.
The other package managers all come with compromises and performance issues, so uv is certainly welcome.
Did you see the performance gains? Even in marginal case (with caching) 4.6s => 0.15s resolution (compared to poetry). Even better when there are cache misses
Respectfully, your dogmatism doesn't seem to serve you with numbers like that