Uv, a fast Python package and project manager
docs.astral.sh
docs.astral.sh
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.
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.
In my book, this happened partly because of disagreement over what tasks the tooling actually needs to do (and because users' needs differ wildly), and a bit because of slow discussions around standards and development of those standards - but mostly because of a poor foundation. It's not that Uv's installer is doing amazing things; it's more that Pip is just badly designed. The internals aren't well factored; it vendors a whole bunch of stuff; it can't offer a usable UI for its own download cache; it doesn't offer an API (and explicitly counsels people to run it in a subprocess); it's designed around the assumption that it will get copied into every virtual environment (even though you don't have to do that any more - except that people don't know this, and it could break if your programs are doing that subprocess trick, unless they declared Pip as a dependency explicitly because who does that?)... the list goes on and on.
> 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)
Python has been around much longer than programmers have been talking about "software ecosystems" in the contemporary sense. Pip isn't in the standard library, so that it can be developed and versioned separately. Making the experience smooth (to the extent that it is) requires special-case support in the form of the `ensurepip` bootstrap and `venv` special-casing Pip (for a while, Setuptools got the same treatment).
There is an extremely strong insistence in that community on making sure not to break older workflows - as much as people perceive them to get broken all the time anyway. All manner of improvements are held back because we still need to support projects that use `setup.py` exclusively and do so in a variety of legacy ways; and because Python still has to work if you don't set up a "project" at all; and shebangs have to work which has implications for how `sys.path` is initialized, etc. The last time there was a concerted attempt to break everything in order to rebuild it properly, users ended up getting 11 years to adapt to 3.x (9, if you account for 3.0 and 3.1 having serious issues and going back on a decision about how to migrate bytes and unicode literals) and in some cases are still grumbling almost 5 more years past the nominal deadline.
>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.
The developers who have been around the longest seem to have more of that background. The best-known names among the relative newcomers all seem to be people working at large tech companies.
Frankly, I'm just happy we didn't land on yet another packaging acronym or snake species :)
This is a poor rationalization for violating norms in open source software. No package manager needs to have a name conflict with a popular package or any package for that matter.
This happens in the Node/React community literally once or more times a year, haha.
> 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
So? 3 letters isn't some magic cutoff; cutting your command down to 3 letters or less doesn't make it suddenly 10x more effective for its users. 4 or 5 letters would be fine, too.
> That's quite a radical take, reducing a language to it's package manager and linter.
Package manager and linter are the most fundamental tools to a programming language in a broader sense, second only to the reference compiler/implementation. The trend in the last couple decades is to, in fact, make all three part of the core, under purview of the same person or group that designs the language itself, and its standard library.
I.e. if you want to "own" the future of a language, the second best option after owning the most popular runtime, is to own the most popular package manager. And I can see this happening already in discussion threads about Python I've been reading over past few months. It's not just that people are excited about UV itself, they're treating Astral as a "thought leader" now.
Again, I'm not saying it's bad, or that Astral would be a bad steward. I'm just surprised to see a previously diverse/anarchic language community to suddenly feel like it'd welcome such stewardship.
> so is VS Code
VS Code is its own thing; sure, it sucked oxygen out of IDE space on UI front, but it also competes against JetBrains in the same space, plus, thanks to LSP, it revitalized Vim and Emacs as viable competitors and enabled creation of even more editors.
In contrast, UV just put a single company in the core position to influence the direction Python as a language takes, which is a new situation for Python - one of the last few popular languages that didn't have a corporate benefactor to start and push it into popularity.
I would argue VS Code where the most popular extension is for the Python language has more influence than Astral.
This seems to represent a schism in the community, although not a constantly explicit one that's pointed at as the cause of conflict (like with, say, the debate over the role of Rust in the Linux kernel).
The original community is so "diverse/anarchic" - and so old - that it causes friction with that first assertion. As far as I know, the idea of a "package manager" being particular to a programming language (as opposed to the operating system) is much newer than Python itself. I was able to use Python for many years before anyone ever suggested a linter to me, either. (Granted, the original lint program for C is from the 70s, but it wasn't seen as a necessity back then - not a compulsory part of a software engineering education, and certainly not treated as fundamental. Actually, I still don't use one.) And I'm still nowhere near "original", having really started using Python in the mid 2000s.
In that frame, it's hard to get people to agree on a project manager, because they don't even agree on the concept of a "project". People write code that they never plan to share with others. People write code that they only expect to share with real-life associates, and don't have the tools to understand why it "only works on my machine" - if you don't have the mental concept of dependencies, you aren't going to be able to specify them, nor properly use a tool to manage them. People just write a few `.py` files in a directory somewhere and expect them to play nice with each other and don't understand why they're shadowing the standard library.
On the other end of the spectrum, people need to interface Python with code in C, FORTRAN and all sorts of other dinosaurs, and they still don't yet have a way to specify their dependencies properly. (Before 2018 or so, there wasn't even a clearly delineated concept of build-time vs runtime dependencies, and people would get into weird chicken-and-egg situations because of needing to run `setup.py` in order to find out what packages are required to run `setup.py`. And now they still run into those problems, because they resist the new changes because of the "useless churn" of `pyproject.toml`.) Sometimes you can hack around that because wheel contents can be anything (including compiled C libraries), but Pip still isn't going to install a custom C compiler into `/usr/bin` (or, heaven forbid, set one up on Windows). And then you have people with giant monorepos trying to figure out where to put `pyproject.toml` files to describe separate "projects" within the same superstructure and build all the separate wheels they want.
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!
* Microsoft Windows
* Microsoft Excel
* Python/Pandas
* Web browsers
They all do great things and deserve all the praise for maintaining backwards compatibility, havoc would have ensued otherwise.
Does not mean that they should not be replaced though.
- 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
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.
`python3 -m pip install <package>' to install it?
And `python3 -m <package>' to run it?
Won't update your pyproject.toml and lock file
'python3 -m <package>' to run it?
Won't install the dependencies you need or set up an insolated environment <package>. 'uvx <package>' will create a venv, make sure you have all the dependencies that <package> needs and run <package>
If you like the per-project venv workflow, and like having it in a specific place (whether that's relative to the project root, or a parallel named venv in `~/.local` somewhere, or anything else), you can set that up as part of your project initialization, too.
Going back to your first comment:
> because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf?
This complaint makes little sense because it mixes and matches things from different categories. `pyproject.toml` isn't even a tool, but a config file that several other tools will rely on - including uv. Poetry and Rye are specifically trying to do the same thing uv is - in fact, Rye is uv's predecessor. Pyenv is for making separate installations of Python - it works alongside venvs, not as an alternative. Pip is just an installer; it's not meant to be compared to full project workflow tools or even to just "package managers".
Expecting one tool to work for everyone is a mistake because of the sheer variety of use cases out there. At the very least, people who only want to install Python applications and libraries are very different from those who seek to distribute their own work. (People in the first group might not even write Python code!)
> This complaint makes little sense because it mixes and matches things from different categories.
It makes all the sense, because I don’t want or have to give a shit about all of this crap.
> `pyproject.toml` isn't even a tool, but a config file
And how many of current tools understand it? Can I make pip save dependencies in it out of the box? No? Then it stays in bullshit list. Arguably it became much better these days, but I remember constant friction when pyproject.toml was just introduced.
> Poetry and Rye are specifically trying to do the same thing uv is - in fact, Rye is uv's predecessor. Pyenv is for making separate installations of Python - it works alongside venvs, not as an alternative. Pip is just an installer; it's not meant to be compared to full project workflow tools or even to just "package managers". Expecting one tool to work for everyone is a mistake because of the sheer variety of use cases out there. At the very least, people who only want to install Python applications and libraries are very different from those who seek to distribute their own work. (People in the first group might not even write Python code!)
Mistake is having thousands of disjoint tools that are stitched together with sticks and shit. I’m glad most modern programming communities got fed up with this crap and lean towards new generation of tooling that can do everything.
I’m absolutely fed up and loathe stitching together billions of half working shite to get semi decent working environment.
Environment management, testing, formatting, libraries and building in one tool should be a minimum requirement.
Poetry kind of tried that, and in doing so failed to allow for a lot of uncommon but vital corner cases. In fact the main reason I gave up on poetry and switched to uv is that uv is a lot less opinionated and happily handles my 'weird' setup and lets me plug in the tools that best serve me rather than requiring me to use it for everything. I have no doubt that uv (or at least the uv 'family') will grow to handle everything sooner or later, but by tackling one piece at a time and making the tools more or less independent also gives flexibility.
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
}
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).
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.
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.
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 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.
If Python was based on Rust, I guess I would not mind, but it is not. Also C is also supported everywhere! And personally I don't see why Rust would be more easy to understand than C. C is really straightforward compared to Rust.
All of that being said, for something as basic and important as a package manager I would except that it is implemented in pure Python so it might easily be hack, modified or fixed without requiring any compilation... Like most of pip and setup tools were.
Just wait for the moment that you can't update some libraries in your code because UV will not work without being updated, but an updated version binary is not available or you need to fix/backport something, so you need to build it. But unfortunately rust devs will not care supported older systems/os, so you are fucked. And you need to upgrade your whole system just to be able to update a simple application library.
`ruff` is also just straight up amazing.
Everything else should do us all a favor and deprecate itself tomorrow.
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.
This is primarily Pip's fault, because it spent many years championing a model where it would be copied into each new "environment you should use for your code".
Most of the benefits people attribute to Python tools because they're "written in a language other than Python", are really just benefits owing to the tool being isolated from the dev environment. And for about the last two years, this has been reasonable with Pip (possible but unreasonably complicated before; now it uses a weird hack, but the experience is pretty smooth). People just don't know about it, in part because they aren't forcefully confronted with it (because copying Pip is still the default for the `venv` standard library module).
It's noteworthy that the standard library does contain `venv` - but not more complex things; technically not even Pip. This rhymes strongly with the philosophy that designed the rest of the standard library. It's the same reason we don't have Requests in there, or, say, `python-dateutil`. (Actually, boto3 gets more than twice as many downloads as Requests, but it's hard to understand why. Working with AWS is surely far more niche than making HTTP connections.)
Requests: there’s urllib in the stdlib. It’s requests just worse.
Working with aws means you’re automating things, ci/cd etc. Many people use python they’ve installed locally for months or years without upgrading.
This is not actually an error that would have occurred to me to make - since one finds out about Poetry from its webpage, which recommends all sorts of custom installation procedures instead.
That's actually a big part of why I gave up on Poetry: the officially blessed install procedure changed a few times, and it became difficult to uninstall because things installed the old way would expect to be uninstalled the old way as well, but that way was already deprecated. Well, I don't remember the exact details, but it was generally that sort of experience.
(Actually, you gave me some insight for something I should do in the installer I'm designing....)
>Working with aws means you’re automating things, ci/cd etc. Many people use python they’ve installed locally for months or years without upgrading.
Yeah. The download count for boto3 is really absurd, though - something like twice a year per person on Earth (https://pypistats.org/top). I guess that has a fair bit to do with them apparently putting out a patch release every business day.
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.
Thankfully the Python ecosystem probably isn't going to adopt this crazy Rust dependency. The Rust nuts are unbelievably and laughably persistent but this is an overcomplicated solution that nobody asked for. You could probably say the same about Rust in the Linux kernel so who knows...
Once Rust can be easily bootstrapped? Like you can build the official Go toolchain from 1.4?
I'd argue Rust in Linux is less of a problem than Linux itself growing out of bounds. Compare seccomp with OpenBSD's pledge/unveil. But there's a reason why Linux is winning by a margin of 100.000x: it's simply more practical, even if less simple.
The speed is one — sometimes I'm in the middle of a project and realise I need to pull in another dependency. Keeping the disruption to flow at a minimum is helpful in those cases. So it's not about deployed performance, it's about mental friction.
The other is I've found Poetry liable to breaking in obscure ways. I don't fully control everything on my work machine, which I suspect is the issue. So far, rye and uv have been smooth, but that might be down to me not having used them long enough.
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.
Ubuntu here.
$ python -m venv --without-pip .venv
$ pip --python .venv/bin/python install -r https://raw.githubusercontent.com/astral-sh/uv/refs/heads/main/docs/requirements.txt
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 ...`.
$ uv venv
Using CPython 3.12.6
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
$ uv pip install -r https://raw.githubusercontent.com/astral-sh/uv/refs/heads/main/docs/requirements.txt
Resolved 43 packages in 283ms
Prepared 4 packages in 64ms
Installed 43 packages in 445ms
...Either way, I don’t see any need to stop people from building better things.
I also like that i can use it with conda environments. Just create conda env, then install with 'uv pip install ....'
Huh cool, I'll have to try that. Conda is great for getting the dependencies for non python code (geos/gdal/cuda etc) but uv is super fast and straightforward (makes building packages much, much easier).
And the point is that you always have to use two package managers when developing python. One that installs python and various non-python libraries and dev tools, and one that installs python libraries. Conda in this scenario is replacing apt as much as anything else.
>why isn't it sufficient to just pin the versions in the requirements.txt?
Because your dependencies have dependencies.
You can, in fact, pin those as well explicitly, and as long as what you pin is a valid solution, Pip will (to my understanding; I haven't done a thorough, explicit test) happily grab exactly what you asked for. And as long as the version number is enough information, that will work for your application.
But some people also want to ensure they use specific exact builds of a package, and verify their hashes. Some of them might be using private indexes (or even mixing and matching with PyPI) and need to worry about supply chain attacks. And at any rate they don't want to account for all the transitive dependencies manually.
In principle, a lock file is a record of such a solution, including all the transitive dependencies, plus file hashes, etc. There isn't perfect agreement about what needs to be in them, which is why discussion of a standard lock file format has been tried a few times and is still ongoing (the current effort is https://peps.python.org/pep-0751/ ; see the linked threads for just some of the related discussion of the concept - there is much more, in the abstract).
That's where pip-tools comes in.
(Though I think the high level interface is the better thing to use)
https://news.ycombinator.com/item?id=42415924
You will notice that it is about the ability to create lock files and nothing else.
And btw I've been using pip-tools for years and it's worked great for me.
uv init; uv add
No more pip freeze, source .venv/bin/activate, deactivate bullcrap.
If you had a bad experience with a different locking tool, sorry to hear it, but that has absolutely nothing to do with the venv itself nor its activation script.
Referring to the entire category in general: mainly, it offers to keep track of what you've installed, and help you set up reproducible scripts to install the same set of dependencies. Depending on the specific tool, additional functionality can vary widely. (Which is part of why there's no standard: there's no agreement on what the additional functionality should be.)
> why do people consider pip to be a problem?
Many problems with Pip are really problems with the underlying packaging standards. But Pip introduces a lot of its own problems as well:
* For years, everyone was expected to use a workflow whereby Pip is copied into each new venv (this is surprisingly slow - over 3 seconds on my machine); users have accidentally invented a million different ways (mainly platform-specific) for `pip` to refer to a different environment than `python` does, causing confusion. (For a while, Setuptools was also copied in by default and now it isn't any more, causing more confusion.) You don't need to do this - since 22.3, Pip has improved support for installing cross-environment, and IMX it Just Works - but people don't seem to know about it.
* Pip builds projects from sdists (thereby potentially running arbitrary code, before the user has had a chance to inspect anything - which is why this is much worse than the fact that the library itself is arbitrary code that you'll import and use later) with very little provocation. It even does this when you explicitly ask it just to download a package without installing it; and it does so in order to verify metadata (i.e., to check that building the sdist would result in an installable wheel with the right name and version). There's wide consensus that it doesn't really need to do this, but the internals aren't designed to make it an easy fix. I have an entire blog post in my planned pipeline about just this issue.
* Pip's algorithm for resolving package dependencies is thorough at the cost of speed. Depending on the kind of packages you use, it will often download multiple versions of a package as sdists, build them, check the resulting metadata, discover that this version isn't usable (either it doesn't satisfy something else's requirement, or its own requirements are incompatible) and try again. (This is partly due to how Python's import system, itself, works; you can't properly support multiple versions of the same library in the same environment, because the `import` syntax doesn't give you a clean way to specify which one you want.)
* Because of how the metadata works, you can't retroactively patch up your metadata for old published versions because e.g. you found out that you've been using something that's deprecated in the new Python release. This has especially bad interactions with the previous point in some cases and explaining it is beyond the scope of a post here; see for example https://iscinumpy.dev/post/bound-version-constraints/ for a proper explanation.
But the main reason why you'd use a package manager rather than directly working with Pip, is that Pip is only installing the packages, not, well, managing them. Pip has some record of which packages depend on which others, but it won't "garbage-collect" for you - if something was installed indirectly as a dependency, and then everything that depends on it is removed, the dependency is still there. Further, trying to upgrade stuff could, to my understanding, cause breakages if the dependency situation is complex enough. And above all of that, you're on your own for remembering why you installed any given thing into the current environment, or figuring out whether it's still needed. Which is important if you want to distribute your code, without expecting your users to recreate your entire environment (which might contain irrelevant things).
That's the main thing keeping me with Poetry.
Other than that I'm super excited.
Seems like the kind of thing that might have some kind of edge case somewhere I'm not thinking of at the moment though.
It wouldn't support hashes, or anything else that you can't do with ordinary dependency specifiers in the project.dependencies list (spec: https://peps.python.org/pep-0508/).
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.
Good enough for me and sans VC risk.
VC-backed tools always make me a little nervous. Sure, Astral says the tools will stay free, and I get that they're targeting enterprise for revenue (private package registries, etc.). But how many times have we heard this before? “Don’t be evil,” right? We’ve seen companies pivot to paywalls or watered-down open-source tools after funding dries up. What guarantees do we have here that uv won't eventually fall into that same trap?
Yeah, Rust is amazing (ruff is a beast), but it’s still a small subset of devs compared to Python. If Astral folds or just loses interest, how easy is this really going to be for the Python community to maintain? Forkable? Sure. But forkable ≠ maintainable when the dev pool is tiny.
Also, what's with using unofficial Python builds by default? Even on platforms where official builds exist (macOS/Windows)? I get that these standalone builds solve certain problems (like bootstrapping), but it feels like a risky shortcut. If those unofficial builds go unsupported or change directions, where does that leave "uv"? Why not at least give users the option to rely on official binaries?
And fragmentation... Python tooling is already a mess. Pip, poetry, conda, pyenv, rye, flit, etc.—do we really need another tool in the mix? Feels like every new tool just promises to "fix packaging forever" but ends up adding another layer of complexity. Why not contribute these improvements to existing tools like pip? Sure, innovation is great, but at what point does it become too much choice and not enough cohesion?
uv looks great, and I love the speed + features. But the ecosystem-level risks here... hard to ignore. Would love to see some stronger guarantees around open-source sustainability, community governance, and alignment with Python standards before jumping in fully. Otherwise, it’s just one more shiny tool that could end up abandoned or locked behind a paywall in 5 years.
The official macOS binaries wouldn't work for uv because they're not portable. They're also taking ownership over the indygreg project which is a great thing for everyone since portable pythons are useful in a lot of contexts. I'm sure they'll start sending some of the portability changes upstream too once they get there.
I don't see how this is criticism.
You don't need to use those, works perfectly fine with whatever Python is on the machine.
> there is an elephant in the room which is that Astral is a VC funded company. What does that mean for the future of these tools? Here is my take on this: for the community having someone pour money into it can create some challenges. For the PSF and the core Python project this is something that should be considered. However having seen the code and what uv is doing, even in the worst possible future this is a very forkable and maintainable thing. I believe that even in case Astral shuts down or were to do something incredibly dodgy licensing wise, the community would be better off than before uv existed.
Python has been around for a long time and there were some attempts at creating a modern package manager for it. If it were feasible to create uv in Python, it would have probably happened by now.
This is the modern equivalent of building key components in Visual C++ for use by Visual Basic people; it kept the unwashed masses away from things they could break.
I think that this is probably the only way you're ever going to fix the horrific experience of using Python in anger. Which is a good thing, Python's a great little language which is let down by being built on sand.
> I don't want to charge people money to use our tools, and I don't want to create an incentive structure whereby our open source offerings are competing with any commercial offerings (which is what you see with a lost of hosted-open-source-SaaS business models).
> What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today.
> An example of what this might look like (we may not do this, but it's helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry. A lot of big companies use uv. We spend time talking to them. They all spend money on private package registries, and have issues with them. We could build a private registry that integrates well with uv, and sell it to those companies. [...]
> But the core of what I want to do is this: build great tools, hopefully people like them, hopefully they grow, hopefully companies adopt them; then sell software to those companies that represents the natural next thing they need when building with Python. Hopefully we can build something better than the alternatives by playing well with our OSS, and hopefully we are the natural choice if they're already using our OSS.
> Facebook's mission is to give people the power to build community and bring the world closer together.
> Our informal corporate motto is "Don't be evil." We Googlers generally relate those words to the way we serve our users – as well we should. But being "a different kind of company" means more than the products we make and the business we're building; it means making sure that our core values inform our conduct in all aspects of our lives as Google employees.
> OpenAi.
Using Rust enables uv to install Python interpreters. That feature uses unofficial third-party binary builds. There are no official binary builds for Linux, but there are such builds for Windows and macOS, yet they use the unofficial third-party builds on those platforms as well. Still, I would consider package and project management to be a separate feature from Python management, and I’d leave it to a different tool (which may be the system package manager on some platforms).
The PyPA does not really exist. The closest to an actual "authority" is the packaging forum on discuss.python.org and the astral folks are active there, see for instance the recent threads on the lockfile standard or the dynamic metadata issue.
> If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether?
People use Python, Astral exists to solve problems of Python people. I'm not sure what the language they are using to write the tool in is relevant. numpy, scipy, tensorflow and many other cornerstones of Python are written in C, C++ and other non Python languages.
> but there are such builds for Windows and macOS
As the author of Rye where I tried very much the same I can attest that the macOS builds are useless for the uv usecase. It's great that Astral is now maintaining the standalone builds which have become a cornerstone for many Python users over the last three years. We have based our entire development environments on those, even though we have not adopted either rye or uv at our company.
Astral to me seem to be targeting a small subset of the community, and their ignorance of the needs outside of it make me very wary of adopting their tools.
Python is a great scripting language and a great language to wrap other stuff. I have other projects in Python that wrap many packages, some in C++/Rust and working on Python is a lot more fun than most of these languages.
When I'm writing this sort of code, I don't have to `.into()`, derive send/sync/debug/whatever, I don't have to `.clone()` my strings when I pass them to multiple places that accept `String`, I don't have to do oh so many things that make my production/critical code better but I care about very little when I'm writing scripts.
I'm much more effective in my 80:20 in Python than in rust though admittedly I'm still on Poetry since uv is releasing vey quickly and my things work "well enough".
(In package management land - I still think most ecosystems haven't caught up to JavaScript + Rust and Python's module systems have weirdness (mod.rs/__init__.py which is unnecessary) but Cargo _is_ overall really nice).
A Python workflow tool written in Python could equally well install every Python interpreter except for the one it itself is using. Those tools generally work fine with any recent installation, and getting one of those is normally not difficult. On Windows the official builds have standalone installers, and Linux normally comes with Python - an isolated development environment (that won't ever mess with the OS) is at most `apt install python3-pip` plus a `venv` invocation away.
But I'm equally well not going to reject a Python tool because it isn't written in Python. (Of course, if it requires installing a massive runtime that I don't already have, or if the compiled binary is larger than an entire Python source tarball - as I found to be the case with uv - then yes, that does count against it.)
> Still, I would consider package and project management to be a separate feature from Python management, and I’d leave it to a different tool
I do as well. I don't want an integrated "project management" tool, either. (I quite like the Unix philosophy for dev tasks.) But I do want an integrated Python application and library installer with a smooth experience, and Pipx isn't quite there yet.
To write things that are not package managers? Are you suggesting not being the right tool for this job implies not being the right tool for any job?
Not every language needs to be good at every thing. Pythons main advantage is inertia, not the things required for this kind of tooling.
It could be built with Python and ship with a standalone Python interpreter to bootstrap though.
More likely, it’s easier to write fast and correct Rust code.