Someone needs to collect the data on UV's rise to popularity and do a sociological study, because from where I sit[0], UV just suddenly came out of nowhere, and despite being confusingly named[1] and backed by a for-profit company, has already captured the hearts and minds of Python developers. Between this and other tooling from that same company, it feels to me that, in the space of less than a year, Python has turned from a community language into a company-led one (like. e.g. Scala).
Not saying whether it's good or bad - just that it's damn curious how this played out. It feels like Python leadership got taken over by some company almost overnight; I'd love to understand how did this happen.
--
[0] - Arguably an outsider to Python community, but like everyone else, downstream of it, and always affected by it, ever since Python became the de-facto standard in Linux as the language between C and Bash.
[1] - Anyone remembers libuv? Spearheading the whole async/await paradigm by powering it in Node.JS, it's one of the most known and talked about libraries ever.
It doesn't feel too surprising to me. The core developer tooling for Python was (/is) about on par with some of the other top languages (C, C++, Java), but lacking when compared to some of the others (Rust, Go, JS/TS). There have also been previous attempts (Pipenv/Poetry) that did prove demand but fell flat in some regards. So it feels like there wasn't any magic, trickery or "take over", but they just filled a void.
Control over uv and ruff (and now also python-build-standalone) doesn't really give Astral significant leverage over Python as a language. They are also quite involved in standardizing many parts of uv via PEPs, which I'm sure the PSF could shoot down if they were overly favoring uv's goals.
Compared to other languages Python leadership also always made the impression to me that they'd rather focus on the language itself and have a looser grip on the ecosystem surrounding it even if that comes with a more fragmented ecosystem (which has already been the status quo for most of Python's existence). I think that makes it very hard to compare to e.g. when Yarn entered the Node.js package manager scene.
It also doesn't feel too surprising that there is little resistance against commercial involvement. Commercially-led programming languages were quite the norm in the past and also seem to be having a comeback (or trying to). In some languages where your median developer has more years of experience and they likely grew up with languages which are more "grassroots" the resistance would be higher. And while I would assume that the people at the PSF also fit that profile, in a high-influx language such as Python, the majority of the Python developers do not.
As a pretty minor note, it's not that we _needed_ a two letter name. We considered hundreds of names and it really came down to what was available on PyPI (because it was table stakes that it could be installed from there). We are aware of libuv — it's used in Python too. However, it's a totally different domain and the name conflict isn't really a problem for our users.
Frankly, I'm just happy we didn't land on yet another packaging acronym or snake species :)
> Someone needs to collect the data on UV's rise to popularity and do a sociological study, because from where I sit[0], UV just suddenly came out of nowhere, and despite being confusingly named[1] and backed by a for-profit company, has already captured the hearts and minds of Python developers.
This happens in the Node/React community literally once or more times a year, haha.
Uv has been awesome so far. It brought the release time for Home Assistant down from an hour and a half to about 15 minutes.
Also installing all the dependencies from scratch used to give you enough time to grab lunch and drink coffee, and now we can only grab the coffee in that time!
I only don't like the .venv in the project directory. It tends to get copied into git or docker. And it makes backup of a project a lot bigger and taking longer because of the many files.
Python was essentially dead for me outside of simple scripts, because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf? Now it's python3 -m pip3 install --user uv; uv init; uv add <package> and I'm good to go.
Or amazing uvx <package>.
Finally someone understands how it is supposed to be done.
There's this weird disconnect I've noticed whenever people talk about Python project management tools in general, and especially about UV.
When they talk about why they like the tool, they say things like "it's not itself written in Python" (sometimes they even seem to think Rust specifically is important), and "it's an all-in-one integrated tool that takes care of all my needs".
But when they talk about what they like about the tool, it's stuff that doesn't actually depend on the prior facts.
People have lots of different ideas about where venvs should go. Choosing an entire tool suite because it agrees with you on this point seems rather sketchy to me. (Obviously you specifically have other reasons, but still.) Managing venvs isn't hard. I use a couple of shell functions in my .bash_aliases to do it the way I want:
# Activate the local venv, which is specially named/located.
alias activate-local="source .local/.venv/bin/activate"
# Run an acceptance test in the local private folder.
alias try-it="(cd .local/ && source run-acceptance-test)"
# PIP (the pipx-installed copy) in the current Environment.
pipe() {
if [ -z ${VIRTUAL_ENV+x} ]
then
echo "No venv active; use pip instead"
else
~/.local/bin/pip --python `which python` "$@"
fi
}
And then I use a simple Python wrapper to create the venv and do an editable install into it. ("Installing dependencies with pyproject.toml" is already supported in Pip, assuming you mean the project's runtime dependencies: `pip install -e .`. Support for other dependency groups defined by new PEPs will hopefully come soon.)
There's no reason Ruff couldn't be a separate tool, mixed and matched with the tools used for other parts of the development process. That's already how people used Black.
Similarly for most of the other jobs. In my book, prefixing `uv tool` to a command line is noise; I don't see how it's better than having separate tools. What you really get from a tool suite is an opinion about which to use.
The issues with Pip don't result from it being written in Python. They result from internal design flaws - partly just generic technical debt, but largely the long-standing assumption that you'll just copy Pip to each environment. (There's code out there that tries to use `subprocess` to run Pip even after the wheel is nominally installed; this isn't assured to work! There's also code that tries to use Pip's API, even though that doesn't actually exist and will break without warning or documentation.) Current versions of Pip have much better support for installing into a different environment from where it's located (which is part of what makes Pipx possible), but awareness is low, and `--without-pip` is not the default for `venv` (that would be really disruptive).
Even slow package resolution is, as far as I can tell, mostly not because of Pip's Python code running slowly. It has more to do with suboptimal caching behaviours and the fact that the metadata standards are so poorly done, and perhaps just some algorithmic issues. But a ton of that work is IO-bound, especially if you have to use sdists for anything (getting accurate metadata tends to involve downloading the entire sdist and building the project, even if it turns out not to be the version that should be installed).
If I was the Python BDFL I would just merge this into pip and solve Python packaging forever. Only decisive action will fix package tooling fragmentation.
Disagree. That seems like it would just slow down progress.
Astral are winning mindshare because the tooling is so much better than the previous generations. That’s the action that’s required here - to be the compelling choice, rather than another choice that’s pretty much like the others and differs only a little.
It's worth remembering here the incident that led to Conda existing in the first place. There has never been a culture that would allow for this. And keep in mind that, aside from being a completely incompatible project, Pip is not part of the standard library.
People don't agree that "package tooling fragmentation" is an actual problem, anyway. I'm one of them. The real problem is that a few of the basic tools (mainly, Pip and Setuptools) don't work properly. They have fundamental design flaws and are ridden with technical debt. The underlying implemented standards have also lagged behind, and Uv can't actually fix that.
But once a solid base is established, I don't actually want to have a single tool making all the package management decisions for me. I want Unix-philosophy tools that handle specific individual development tasks, built around a proper, integrated user tool for installing applications and libraries (Pipx would be very close to such a tool, if it exposed its underlying Pip copy more elegantly and if Pip didn't suck). I don't want someone else's "project manager" to decide for me what build backend to use, or even to just bundle one. And I'm perfectly happy using `build` as a build frontend, `twine` as a PyPI uploader etc. Writing `uv upload` or whatever it actually uses, is not an improvement to me.
Have they figured out yet how this VC backed company will make money? It's quite important imo, I don't want a watered down experience 5 years from now.
Pydantic had a nice model where the open source tool is fantastic, but they now sell a cloud based logging system around that. There will be some enterprise tooling around UV that they could sell while keeping the tool itself free
It sounds like they're not yet at the stage where they need to worry about it, though I've heard Charlie mention making an easy to host package registry as one offering.
For me it is not great because of the new requirement for "rust" for basic Python.
Does not make any sense.
Especially if the main selling point is "speed". I never encounter cases where the pip install equivalent was particularly unbearably long except in very badly designed and broken projects. The kind of one that that import every possible dependency (nom style) with pinning things on broken and incompatible set of dependencies...
Also, I like very much the concept of one tool for one usage. And having venv and pip is great, having one tool cluster mixing everything is not. Sure in most dummy usage cases it will be great, but you have more chance of clusterfucks and complicated unresolvable issues. Even more if developers are opinionated on a single way to do something.
> For me it is not great because of the new requirement for "rust" for basic Python. Does not make any sense.
The language of choice for such core functionality in the past was C. I'm not sure how much spelunking you did in the core interpreter, but the Astral rust code is much easier to understand and modify.
I’ve been missing a python tool like this that isn’t written in python. Conda was good in this regard - having a distribution without first installing python is a massive improvement to the «getting started» problems in python.
I've really never understood this objection. Users that need multiple actual versions of Python (as opposed to separate venvs) are usually more technically sophisticated; Python for Windows comes as an installer and Linux is generally dependent on it already (and a usable dev environment is only `python -m venv` away). But more to the point, writing an application in another language - or at all - isn't relevant to solving that problem. There's no reason you couldn't have a downloadable freestanding Pip package that comes with its own Python - just have the user unpack a zip archive or whatever, and have all the needed files in the right place. That just doesn't happen because it seems backwards.
There's been an initiative to standardize portable Python binaries that would facilitate that sort of approach (and make them installable from PyPI), called PyBI (https://peps.python.org/pep-0711/). Yes, you still have to do that installation. But at least in principle, you don't need an installer for it; you could download from the PyPI website and unzip the wheel.
Welcome to the bootstrapping problem. The original take is "how do I build a C compiler without a C compiler", and some amazingly gifted people from the GNU/Guix team managed to take it to its logical conclusion - and wrote a 357 byte piece of annotated machine code, from which an entire distro can be bootstrapped.
On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency.
Not quite sure what kind of projects people are talking about here, where Poetry takes too long. Must be pretty massive sets of dependencies. Maybe huuuge monoliths? What I usually do is build a venv in a docker container of a service and then that gets deployed. I don't see a problem, if this took a minute or two, but so far it never did take that long.
The answer to the question about VC funding is weirdly obvious at any sort of distance away from the emotive things.
Communities should probably cautiously welcome VC funding for well-integrated community members solving hard, core problems with correctly-licensed contributions back to the community, as long as that effort doesn't divert community engineering focus away from long-term community goals and towards the startup's goals in non-beneficial way.
They should be more cynical about things that don't happen this way, but then they can keep doing their own thing anyway.
Ondsel found the money for two major core technical problems to be addressed in FreeCAD, and seems to have had a pretty positive impact on release-oriented thinking in general. They then folded. It is a loss, but essentially none of the work was lost.
Frankly I am not sure if the "written in Rust" element here is culturally beneficial in the long term or not; I don't know enough about Python or really anything about Rust.
This venv creation is instantaneous, because it doesn't install Pip in the new venv. On my 10-year-old machine, with cached packages (it still has to unzip everything and move it around), the installation takes about 8.5 seconds.
I have some wrapper scripts defined locally to smooth out this process; I can do `make-project-venv` (which puts the venv in `.local/.venv` and also attempts to install the current project with `pip --python ... install -e .`) and then `activate-local` and then `pipe install ...`.
I have noticed a spike in attention to UV since Anthropic announced the Model Context Protocol (MCP). After using it for MCP development, I am moving from pyenv to uv! https://www.anthropic.com/news/model-context-protocol
Super fast installs - when it works. I had problems on Ubuntu for linux (WSL) with a clang dependency, which i could never solve. But on linux boxes, it's so much better than pip/conda/etc.
I also like that i can use it with conda environments. Just create conda env, then install with 'uv pip install ....'
I have only ever really used venv. Poetry was fine but didn't give me any additional benefits that I could see. What does this offer? And more broadly, why do people consider pip to be a problem? I have literally never had any issues with it in any of my projects.
Personally, I use it for everything right now. It's faster to do `uv init` and then add your dependencies with `uv add` and than just `uv run <whatever>`. You can argue that poetry does the same, but `uv` also has a pipx alternative, which I find myself using more than the package manager that my distro offers, since I never had compatibility issues with packages.
If they are using standard compliant tools like pyenv, venv and pip then uv will play nicely with that. In fact I'm working on a project like that right now. The 'official' guidelines says to use pip and venv, but I'm using uv and no one else notices.
If on the other hand they're using a more optionated tool like poetry then it won't work as well, but that has more to do with poetry doing its own thing and not playing nice with other tools.
Honestly? It's excellent but it's Python only, I dream a day where NixOS/Guix Systems will be so common that anybody will use their approach to develop in any language (and the future Nix is something more digestible and Guix system will care more about the desktop, as side dreams)...
[+] [-] TeMPOraL|1 year ago|reply
Not saying whether it's good or bad - just that it's damn curious how this played out. It feels like Python leadership got taken over by some company almost overnight; I'd love to understand how did this happen.
--
[0] - Arguably an outsider to Python community, but like everyone else, downstream of it, and always affected by it, ever since Python became the de-facto standard in Linux as the language between C and Bash.
[1] - Anyone remembers libuv? Spearheading the whole async/await paradigm by powering it in Node.JS, it's one of the most known and talked about libraries ever.
[+] [-] hobofan|1 year ago|reply
Control over uv and ruff (and now also python-build-standalone) doesn't really give Astral significant leverage over Python as a language. They are also quite involved in standardizing many parts of uv via PEPs, which I'm sure the PSF could shoot down if they were overly favoring uv's goals.
Compared to other languages Python leadership also always made the impression to me that they'd rather focus on the language itself and have a looser grip on the ecosystem surrounding it even if that comes with a more fragmented ecosystem (which has already been the status quo for most of Python's existence). I think that makes it very hard to compare to e.g. when Yarn entered the Node.js package manager scene.
It also doesn't feel too surprising that there is little resistance against commercial involvement. Commercially-led programming languages were quite the norm in the past and also seem to be having a comeback (or trying to). In some languages where your median developer has more years of experience and they likely grew up with languages which are more "grassroots" the resistance would be higher. And while I would assume that the people at the PSF also fit that profile, in a high-influx language such as Python, the majority of the Python developers do not.
[+] [-] zanie|1 year ago|reply
Frankly, I'm just happy we didn't land on yet another packaging acronym or snake species :)
[+] [-] toastercat|1 year ago|reply
This happens in the Node/React community literally once or more times a year, haha.
[+] [-] dist-epoch|1 year ago|reply
> confusingly named
The name needs to be ultra-short, there are only so many 2 and 3 letter words which are not already taken on linux/windows.
> Python has turned from a community language into a company-led one
That's quite a radical take, reducing a language to it's package manager and linter.
> backed by a for-profit company
so is VS Code
[+] [-] joostlek|1 year ago|reply
Also installing all the dependencies from scratch used to give you enough time to grab lunch and drink coffee, and now we can only grab the coffee in that time!
[+] [-] nullify88|1 year ago|reply
[+] [-] outlore|1 year ago|reply
- Putting .venv automatically into the project directory
- Installing dependencies with pyproject.toml
- Installing any Python version
- Fast pip installs
- uvx (like npx)
- Ruff formatter and linter, made by the same people
Python used to give me a headache, now I tend to reach for it more often, exclusively thanks to uv
[+] [-] amai|1 year ago|reply
[+] [-] wiseowise|1 year ago|reply
Python was essentially dead for me outside of simple scripts, because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf? Now it's python3 -m pip3 install --user uv; uv init; uv add <package> and I'm good to go. Or amazing uvx <package>. Finally someone understands how it is supposed to be done.
[+] [-] zahlman|1 year ago|reply
When they talk about why they like the tool, they say things like "it's not itself written in Python" (sometimes they even seem to think Rust specifically is important), and "it's an all-in-one integrated tool that takes care of all my needs".
But when they talk about what they like about the tool, it's stuff that doesn't actually depend on the prior facts.
People have lots of different ideas about where venvs should go. Choosing an entire tool suite because it agrees with you on this point seems rather sketchy to me. (Obviously you specifically have other reasons, but still.) Managing venvs isn't hard. I use a couple of shell functions in my .bash_aliases to do it the way I want:
And then I use a simple Python wrapper to create the venv and do an editable install into it. ("Installing dependencies with pyproject.toml" is already supported in Pip, assuming you mean the project's runtime dependencies: `pip install -e .`. Support for other dependency groups defined by new PEPs will hopefully come soon.)There's no reason Ruff couldn't be a separate tool, mixed and matched with the tools used for other parts of the development process. That's already how people used Black.
Similarly for most of the other jobs. In my book, prefixing `uv tool` to a command line is noise; I don't see how it's better than having separate tools. What you really get from a tool suite is an opinion about which to use.
The issues with Pip don't result from it being written in Python. They result from internal design flaws - partly just generic technical debt, but largely the long-standing assumption that you'll just copy Pip to each environment. (There's code out there that tries to use `subprocess` to run Pip even after the wheel is nominally installed; this isn't assured to work! There's also code that tries to use Pip's API, even though that doesn't actually exist and will break without warning or documentation.) Current versions of Pip have much better support for installing into a different environment from where it's located (which is part of what makes Pipx possible), but awareness is low, and `--without-pip` is not the default for `venv` (that would be really disruptive).
Even slow package resolution is, as far as I can tell, mostly not because of Pip's Python code running slowly. It has more to do with suboptimal caching behaviours and the fact that the metadata standards are so poorly done, and perhaps just some algorithmic issues. But a ton of that work is IO-bound, especially if you have to use sdists for anything (getting accurate metadata tends to involve downloading the entire sdist and building the project, even if it turns out not to be the version that should be installed).
[+] [-] Evidlo|1 year ago|reply
[+] [-] aidos|1 year ago|reply
Astral are winning mindshare because the tooling is so much better than the previous generations. That’s the action that’s required here - to be the compelling choice, rather than another choice that’s pretty much like the others and differs only a little.
[+] [-] zahlman|1 year ago|reply
People don't agree that "package tooling fragmentation" is an actual problem, anyway. I'm one of them. The real problem is that a few of the basic tools (mainly, Pip and Setuptools) don't work properly. They have fundamental design flaws and are ridden with technical debt. The underlying implemented standards have also lagged behind, and Uv can't actually fix that.
But once a solid base is established, I don't actually want to have a single tool making all the package management decisions for me. I want Unix-philosophy tools that handle specific individual development tasks, built around a proper, integrated user tool for installing applications and libraries (Pipx would be very close to such a tool, if it exposed its underlying Pip copy more elegantly and if Pip didn't suck). I don't want someone else's "project manager" to decide for me what build backend to use, or even to just bundle one. And I'm perfectly happy using `build` as a build frontend, `twine` as a PyPI uploader etc. Writing `uv upload` or whatever it actually uses, is not an improvement to me.
[+] [-] dagw|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] cinntaile|1 year ago|reply
[+] [-] the_mitsuhiko|1 year ago|reply
[+] [-] eddsolves|1 year ago|reply
[+] [-] bdzr|1 year ago|reply
[+] [-] qprofyeh|1 year ago|reply
[+] [-] greatgib|1 year ago|reply
Especially if the main selling point is "speed". I never encounter cases where the pip install equivalent was particularly unbearably long except in very badly designed and broken projects. The kind of one that that import every possible dependency (nom style) with pinning things on broken and incompatible set of dependencies...
Also, I like very much the concept of one tool for one usage. And having venv and pip is great, having one tool cluster mixing everything is not. Sure in most dummy usage cases it will be great, but you have more chance of clusterfucks and complicated unresolvable issues. Even more if developers are opinionated on a single way to do something.
[+] [-] the_mitsuhiko|1 year ago|reply
The language of choice for such core functionality in the past was C. I'm not sure how much spelunking you did in the core interpreter, but the Astral rust code is much easier to understand and modify.
[+] [-] benreesman|1 year ago|reply
`ruff` is also just straight up amazing.
Everything else should do us all a favor and deprecate itself tomorrow.
[+] [-] pletnes|1 year ago|reply
[+] [-] zahlman|1 year ago|reply
There's been an initiative to standardize portable Python binaries that would facilitate that sort of approach (and make them installable from PyPI), called PyBI (https://peps.python.org/pep-0711/). Yes, you still have to do that installation. But at least in principle, you don't need an installer for it; you could download from the PyPI website and unzip the wheel.
[+] [-] rollcat|1 year ago|reply
On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency.
https://bootstrappable.org
[+] [-] zelphirkalt|1 year ago|reply
[+] [-] throw646577|1 year ago|reply
Communities should probably cautiously welcome VC funding for well-integrated community members solving hard, core problems with correctly-licensed contributions back to the community, as long as that effort doesn't divert community engineering focus away from long-term community goals and towards the startup's goals in non-beneficial way.
They should be more cynical about things that don't happen this way, but then they can keep doing their own thing anyway.
Ondsel found the money for two major core technical problems to be addressed in FreeCAD, and seems to have had a pretty positive impact on release-oriented thinking in general. They then folded. It is a loss, but essentially none of the work was lost.
Frankly I am not sure if the "written in Rust" element here is culturally beneficial in the long term or not; I don't know enough about Python or really anything about Rust.
[+] [-] andrewinardeer|1 year ago|reply
Ubuntu here.
[+] [-] zahlman|1 year ago|reply
I have some wrapper scripts defined locally to smooth out this process; I can do `make-project-venv` (which puts the venv in `.local/.venv` and also attempts to install the current project with `pip --python ... install -e .`) and then `activate-local` and then `pipe install ...`.
[0]: https://pip.pypa.io/en/stable/news/#v22-3
[+] [-] zanie|1 year ago|reply
[+] [-] kthejoker2|1 year ago|reply
[+] [-] short_sells_poo|1 year ago|reply
[+] [-] sswatson|1 year ago|reply
Either way, I don’t see any need to stop people from building better things.
[+] [-] thangngoc89|1 year ago|reply
[+] [-] ilalex|1 year ago|reply
[+] [-] Techtsunami|1 year ago|reply
[+] [-] jamesblonde|1 year ago|reply
I also like that i can use it with conda environments. Just create conda env, then install with 'uv pip install ....'
[+] [-] These335|1 year ago|reply
[+] [-] chad1n|1 year ago|reply
[+] [-] eternityforest|1 year ago|reply
That's the main thing keeping me with Poetry.
Other than that I'm super excited.
[+] [-] zanie|1 year ago|reply
[+] [-] Raed667|1 year ago|reply
[+] [-] dagw|1 year ago|reply
If on the other hand they're using a more optionated tool like poetry then it won't work as well, but that has more to do with poetry doing its own thing and not playing nice with other tools.
[+] [-] ilalex|1 year ago|reply
[+] [-] vegabook|1 year ago|reply
Good enough for me and sans VC risk.
[+] [-] kkfx|1 year ago|reply