I hadn't paid any attention to rust before uv, but since starting to use uv, I've switched a lot of my performance-sensitive code dev to rust (with interfaces to python). These sorts of improvements really do improve my quality of life significantly.

My hope is that conda goes away completely. I run an ML cluster and we have multi-gigabyte conda directories and researchers who can't reproduce anything because just touching an env breaks the world.

I'm surprised by how much I prefer prepending "uv" to everything instead of activating environments - which is still naturally an option if that's what floats your boat.

I also like how you can manage Python versions very easily with it. Everything feels very "batteries-included" and yet local to the project.

I still haven't used it long enough to tell whether it avoids the inevitable bi-yearly "debug a Python environment day" but it's shown enough promise to adopt it as a standard in all my new projects.

I predict it'll be the best and then the 'worst' thing: they'll go hard on monetisation.

Just look at this post: 1839 points and 1048 comments! That is insane. It's captured the hearts and minds of Python devs and I'm sure they know it.

I'm not against projects making money, just remember you'll likely pay a price later on once you invest in more of Astral's ecosystem. It's just temporarily free.

For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script:

  #!/usr/bin/env -S uv run --script
  # /// script
  # requires-python = ">=3.11"
  # dependencies = [ "modules", "here" ]
  # ///

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool.

Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my primary language for everything. But then I remember that Python is dog slow compared to other languages with comparable ergonomics and first-class support for static typing, and...idk it's a tough sell.

I know the performance meta in Python is to...not use python (bind to C, Rust, JVM) - and you can get pretty far with that (see: uv), but I'd rather spend my limited time building expertise in a language that isn't constantly hemorrhaging resources unless your code secretly calls something written in another language :/

There are so many good language options available today that compete. Python has become dominant in certain domains though, so you might not have a choice - which makes me grateful for these big steps forward in improving the tooling and ecosystem.

The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see uv doesn't make this easy.

These rust based tools really change the idea of what's possible (when you can get feedback in milliseconds). But I'm trying to figure out what Astral as a company does for revenue. I don't see any paid products on their website. They even have investors.

So far it seems like they have a bunch of these high performance tools. Is this part of an upcoming product suite for python or something? Just curious. I'm not a full-time python developer.

I must be the odd man out but I am not a fan of uv.

1. It tries to do too many things. Please just do one thing and do it well. It's simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command.

2. You end up needing to use `uv pip` so it's not even a full replacement for pip.

3. It does not play well with Docker.

4. It adds more complexity. You end up needing to understand all of these new environmental variables: `UV_TOOL_BIN_DIR`, `UV_SYSTEM_PYTHON`, `UV_LINK_MODE`, etc.

I'd put type annotations and GIL removal above UV without a second thought. UV is still young and I hit some of those growing pains. While it is very nice, I'm not going to put it up there with sliced bread, it's just another package manager among many

Idk, for me ruff was more of a game changer. No more explaining why we need both flake8 and pylint (and isort), no more flake8 plugins... Just one command that does it all.

UV is great but I use it as a more convenient pip+venv. Maybe I'm not using it to it's full potential.

Can't agree more. We were using pyenv+poetry before and regularly had to pin our poetry version to a specific one, because new poetry releases would stall trying to resolve dependencies.

pyenv was problematic because you needed the right concoction of system packages to ensure it compiled python with the right features, and we have a mix of MacOS and Linux devs so this was often non-trivial.

uv is much faster than both of these tools, has a more ergonomic CLI, and solves both of the issues I just mentioned.

I'm hoping astral's type checker is suitably good once released, because we're on mypy right now and it's a constant source of frustration (slow and buggy).

As someone who generally prefers not to use python in a production context (I think it's excellent for one-off scripts or cron jobs that require more features then what bash provides), I agree with this sentiment. I recently wrote some python (using uv) and found it to be pleasant and well-integrated with a variety of LSPs.

    > Instead of 
    >
    > source .venv/bin/activate
    > python myscript.py
    >
    > you can just do
    >
    > > uv run myscript
    >

Side rant: yes I get triggered whenever someone tells me "you can just" do this thing that is actually longer and worse than the original.

Before uv, I was fairly happy with pyenv + venv + pip for development and pipx for running "tools". IMO, the specific things uv improves upon are:

  - Faster dependency resolution. In fact, everything uv does is extremely fast.
  - Better ergonomics in a dozen ways (`uv run` instead of activating the virtual env, support for script metadata to run scripts with dependencies, uv add to modify the pyproject.toml (that it created for you), etc.)
  - Stack of one tool instead of four+
  - Easier Python installation (although I usually use both pyenv and uv on my machine)

This article appears to be NOT about someone who discovered uv after using venv/pip, but rather an article about someone who discovered uv after not using virtual environments at all, and is mostly excited about the cleanliness of virtual environments.

Couldn't agree more.

Arguably this article is missing one of the biggest benefits: Being able to make Python scripts truly self-contained by including dependencies via a PEP 723 inline header and then running them via `uv run <script.py>` [1].

It's made Python my language of choice for one-off scripts easily shareable as gists, scp-able across systems etc.

[1] https://pybit.es/articles/create-project-less-python-utiliti...

UV lets me love using Python. There are other languages, mostly Lisp languages, that I have always liked better but my workflow with UV is so pleasant that I find myself not minding Python the language, even looking forward to using it.

General comment: using Rust for utilities and libraries has revitalized Python.

UV and the crew at Astral really moved the Python packaging community forward.

I would love to see them compete with the likes of Conda and try to handle the Python C extension story.

But in the interim, I agree with everyone else who has already commented, Pixi which is partly built atop of UV’s solver is an even bigger deal and I think the longer term winner here.

Having a topologically complete package manager who can speak Conda and PyPi, is amazing.

https://pixi.sh/latest/

Seems like a commercial blog. And imho hatch is better from a Foss perspective.

UV means getting more strings attached with VC funded companies and leaning on their infrastructure. This is a high risk for any FOSS community and history tells us how this ends….

This blog very strongly echoes my own experiental sense of the field of play.

It's just simpler to use, and better overall. It's reduced friction significantly.

I think the Python community should put it as a first preference vehicle, and be respectful to the prior arts, and their developers, but not insist they have primacy.

I love how uv allows me to not think of all the options anymore.

virtualenv, venv, pyenv, pipenv... I think at one point the recommended option changed because it was integrated into Python, but I can't even remember which is which anymore.

Such a pleasure to finally have just one, for maybe... ~99% of my needs.

I love uv. But the post starts with a simple install using a oneliner curl piping to sh, which is such a big attack surface area… I would much rather have a much longer one liner that increases safety.

Everything from the astral team has been superb, I don't want to use Python without ruff & uv. Yet to try "ty", anyone used it?

But what was wrong with pip, venv and pyproject.toml in the first place? I just keep a system installation of python for my personal things and an environment for every project I'm working on. I'd get suspicious if a developer is picky about python versions or library versions like what crazy programs are you writing?

curl|sh and iwr|iex chills my spine, no one should recommend these methods of installation in 2025. I'm against closed computers but I'm also against reckless install. Even without the security concerns these way of installation tends to put files in a whole random places making it hard to manage and cleanup.

I still feel bitten by diving into poetry when starting some projects. Has the ecosystem fully moved on to uv, now? Do they have good influence on what python's main ecosystem is moving to?

I think ruff is the best thing to happen to the python ecosystem in a decade, it really sold the entire community on the difference fast native tooling could make.

What about Pixi[1]? It has become an irreplaceable part of my dev stack. Fantastic for tool + library version management. It has replaced a number of tools for me and greatly simplified bootstrapping in a new environment (like lxc containers when I am experimenting with stuff) or creating a lightweight sandbox for AI agents.

1. https://pixi.sh/latest/

I have to say that I am extremely reluctant to switch over to yet another python management system (packaging, environment, python version). Every few years someone says: this is it. Switch to poetry! Okay, I did. And, at least for some academic packages, psychopy I'm looking at you, it was a friggin disaster.

so. will uv install psychopy (say version 3.2.4)?

Or is it a corporate grab to gain more influence in the ecosystem? I like the idea, but for profit backing is out of the question. This lesson has been learned countless times.

(off topic) The code chunks in the article use a ligature font, so ">=" is rendered in a way that makes you stop to think how to type it - which is especially confusing since the context is not exactly math. Down with ligatures and extra cognitive load!

Does uv handle CUDA versioning? This is the big reason I'm still on conda -- I can save a whole environment with `conda list --explicit`, including CUDA stuff, and I can set up a new machine with the same environment just from that file.

The best thing to happen to the Python ecosystem would be something that unites pip and conda. Conda is not going anywhere given how many packages depend on non-python binaries, especially in enterprise settings.

uv is great. I am a Ruby developer and I always loathed having to work with Python libraries because of how bad the tooling was. It was too complex to learn for the one-off times that I needed it and nothing worked properly.

Now with uv everything just works and I can play around easily with all the great Python projects that exist.

Been using pip and venv for long. I get uv is faster, but I don't get why people drool over it this much. What is wrong with pip + venv? I build webapps so perhaps I don't see issues in ML world

Using Python on and off for OS scripting since version 1.6.

It has always been enough to place installations in separate directories, and use the same bash scripts for environment variables configuration for all these years.

From the article:

> uv is an incredibly powerful simplification for us that we use across our entire tech stack. As developers, we can all work with identical Python installations, which is especially important given a number of semi-experimental dependencies that we use that have breaking changes with every version. On GitHub Actions, we’re planning to use uv to quickly build a Python environment and run our unit tests. In production, uv already manages Python for all of our servers.

> It’s just so nice to always know that Python and package installation will always be handled consistently and correctly across all of our machines. That’s why uv is the best thing to happen to the Python ecosystem in a decade.

I can only conclude, that the author of the article, and perhaps even the organization they work in, is unaware of other tools that did the job long before uv. If they really value reproducibility that much, how come they didn't look into the matter before? Things much have been really hastily stitched together, if no one ever looked at existing tooling before, and only now they make things reproducible.

I guess reproducibility is still very much a huge problem, especially in jobs, where it should be one of the most important things to take care of: Research. ("Astronomer & Science Communicator" it says on the website). My recommendation is: Get an actual software developer (at least mid-level) to support your research team. A capable and responsibly acting developer would have sorted this problem out right from the beginning.

I am glad they improved their project setups to the level they should be at, if they want to call it research.

Super agree! Love how uv installs packages in parallel! It made installs 30 seconds from 5 minutes during `uv pip install unsloth`!

This blog post was really helpful to understand the ecosystem: https://alpopkes.com/posts/python/packaging_tools/

It mentions uv at the end and rye at first (which use uv internally).

I’m surprised not to see a discussion of the biggest drawback: despite being fewer characters, “uv” is harder to type than “pip”. It requires two different hands to participate and a longer reach with my left index finger. pip is convenient – just a little rattle off with my right hand.

I thoroughly enjoy uv, having used poetry and requirements.txt prior, but it does come with its faults in a large codebase. Admittedly, I don’t know whether they re due to uv’s infancy, or PEP restrictions.

For example:

    1. uv sync should update by default (like poetry)
    2. uv lock revision and dependency resolver keep changing and it makes it hard to figure out if changes to our uv.lock are real or due to separate versions of uv among developers
    3. uv pre-release dependency rules should be able to be disabled with either a sys_marker or specific case like pinning a version
 

Uv existing is what made me willing to use Python as my primary prototype/experiment language!

either conda is that old now or it seems a bit of a hyperbole.

haven used it personally, uv is quite fast and nice to work with at first. definitely nice if you work in a team that fully utilise its potential. however, there felt a lot of parallels with the node.js universe and switching to .venv / localized environments bloats up the system when you work with a boilerplate env that is the same across projects.

the additional files generated are also less human-readable compared to a requirements.txt and the workflow felt a bit more involved for individual users imho. it definitely has a place in the ecosystem, but personally don't find it ready to replace everything else yet.

Can I just start using python if I've already got a bunch of projects manage with venv / pyenv / virtualenv ( and tbh I've kinda got into a confused mess with all these venv things, and at this point just hope they all keep working...)

Rust is the best thing to happen to the Python (and JS) ecosystem in a decade. Once people realized that the tooling doesn't need to be written in the same language as the target language, it opens up all sorts of performance possibilities.

Python is not my first language but I've always liked it. But project and dependency management was always a bit meh and an afterthought.

Over the years, I've tried venv, conda, pipenv, petry, plain pip with requirements.txt. I've played with uv on some recent projects and it's a definite step up. I like it.

Uv actually fixes most of the issues with what came before and actually builds on existing things. Which is not a small compliment because the state of the art before uv was pretty bad. Venv, pip, etc. are fine. They are just not enough by themselves. Uv embraces both. Without that, all we had was just a lot of puzzle pieces that barely worked together and didn't really fit together that well. I tried making conda + pipenv work at some point. Pipenv shell just makes using your shell state-full just adds a lot of complexity. None of the IDEs I tried figured that out properly. I had high hopes for poetry but it ended up a bit underwhelming and still left a lot of stuff to solve. Uv succeeds in providing a bit more of an end to end solution. Everything from having project specific python installation, venv by default without hassle, dependency management, etc.

My basic needs are simple. I don't want to pollute my system python with random crap I need for some project. So, like uv, I need to have whatever solution deal with installing the right python version. Besides, the system python is usually out of date and behind the current stable version of python which is what I would use for new projects.

My biggest frustration is the lack of a good universal REPL to just play around with. It's frustrating how I have to run `uvx --with x,y,z ipython` every single time I just want to spin up some python code which may or may not use packages. (Hard to overstate how annoying it is to type out the modules list).

To me, Python's best feature is the ability to quickly experiment without a second thought. Conda is nice since it keeps everything installed globally so I can just run `python` or iPython/Jupyter anywhere and know I won't have to reinstall everything every single time.

God yes. I got dragged into the uv when I started using copyparty and I am a fanatical admirer ever since. I also use pipx to install tools often. I really don't understand why you can't just pip install something globally. I want this package to be available to me EVERYWHERE, why can't I do it? I only use python recreationally because everyone uses python everywhere and you can't escape it. So there is a massive possibility I am simply wrong and pip-installing something globally is a huge risk. I'm just not understanding it.

Every time I see one of these comment threads it seems like uv desperately needs a better home page that doesn’t start with a long list of technical stuff. It’s really simple to use, in fact so simple that it confuses people!

The home page should be a simplified version of this page buried way down in the docs: https://docs.astral.sh/uv/guides/projects/

It's surprising to me how long it can take for some languages to get decent package management solutions. There are no silver bullets because it's tricky to "encode" compatibility in a version number. I personally think semver helped a little and damaged a lot more by selling a pseudo solution that stands no chance to solve the real problem it needs to.

Maven has always been a very good solution. I think Bazel is too, but haven't had much experience with it.

Yes, uv is probably the best thing to happen to the Py ecosystem in the last decade. That is mainly because the rest of the ecosystem is somewhere between garbage fire and mediocre at best. uv in itself is a great tool, I have no complaints about it whatsoever! But we have to remember just how bad the rest of things are and never forget that everything's still in a pretty bad state even after more than 3 ** DECADES ** of constant evolution.

I either want one universal tool that can manage this sort of thing across multiple languages (eg. devenv) or a native, built-in tool (eg. go's tooling). I don't see how this is any different from all the previous incarnations of Python's project/package management tools. The constant churning of 3rd party tooling for Python was one of the main reasons I mostly stopped using it for anything but smaller scripts.

Yes, agree. At first I still use pyenv, or mise to manage python version, now that uv does that, uv is the only tool I need for everything in Python env.

And still there are some annoying issues:

  dependencies = [
      "torch==2.8.0+rocm6.4",
      "torchvision==0.23.0+rocm6.4",
      "pytorch-triton-rocm==3.4.0",
  ...
  ]

Genuinely trying to learn here - what's the major advantage of using uv over conda?

(Transparently, I'm posting this before I've completed the article.)

Can someone steelman the python tooling ecosystem for me? Having a new packaging / dependency manager every few years seems excessive.

It's too bad they didn't call it something else besides uv given there's already other "uv" named tools like: uvicorn, uvloop, pyuv - and those three almost hvae more in common with each other than the uv build/project tool. Then there's also libuv.

I completely agree. Deploying Python packages like MCP servers has been a real game changer. I'm so glad the days of wrestling with conda environments and Jupyter kernels are behind us. I used to start personal projects, decide to clean up my Python setup first, and inevitably give up on the project after getting lost in the cleanup.

I have one problem with uv as of now, and it's more of an annoyance. It doesn't seem to understand the concept of >= when it's trying to resolve a local wheel I built and use. If I have 6.4.1 published on GitLab and the pyproject says $WHEEL_NAME>=6.2.0, it still goes to look for 6.2.0 (which I deleted) and errors out.

I recently discovered you can use uv to run code direct from a git repo.

No need to clone/manually install packages first. E.g. `uvx --from "git+https://github.com/richstokes/meshtastic_terminal.git" meshtastic-tui`

It’s puzzling why Python became the de facto standard scripting language rather than Ruby when the tooling was so inferior.

I haven't tried uv yet, but I did use it's precursor - rye.

I had to update some messy python code and I was looking for a tool that could handle python versions, package updates, etc. with the least amount of documentation needing be read and troubleshooting.

Rye was that for me! Next time I write python I'm definitely going to use uv.

Does anyone know how Uv performs in the Geo-Package-Space? (i.e. GDAL, geopandas, cartopy, pyproj, rasterio etc.) This is the one area where I still find that conda performs best because all the authors of these packages use the conda-forge channel themselves for testing and production.

A very accessible and gentle introduction for the scientific set who may still be largely stuck on Conda. I liked it!

Would be nice to systematically start with problems of the non-uv world to highlight the specific value of uv.

But nice read!

I love using uv and would be supper happy if it allowed me not only to add and remove

uv add package

uv remove package

But also to upgrade a package and upgrade all packages in the pyproject.toml . The uv sync --upgrade can already do this in uv.lock , but not in pyproject.toml

I can only agree. I'm not an python expert, but I always struggled when installing a new package and got the warning, that it could break the system packages, or when cloning an existing repo on a new installed system. Always wondered, why it became so "complicated" over the years.

This looks awesome.

But why is it the Windows installation is to execute a script off the Internet with bypassed security isolations?

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

   [project]
   name = "my_project"
   version = "1.0.0"
   requires-python = ">=3.9,<3.13"
   dependencies = [
     "astropy>=5.0.0",
     "pandas>=1.0.0,<2.0",
   ]

The best things since f-strings...

I'm teaching (strongly recommending/forcing using) uv in all my courses now.

I am a bit skeptical.

You only have to look at the ruby ecosystem and the recent mass-expulsion of long-term developers from rubygems/bundler via RubyCentral going full corporate-mode ("we needs us some more moneeeeeys now ... all for the community!!!" - or something). While one COULD find pros in everything, is what is happening in different programming languages really better for both users and developers? I am not quite convinced here.

I am not saying the prior status quo was perfect. What I am saying is ... I am not quite convinced that the proposed benefits are real. In fact, I find managing multiple versions actually annoying. I should say that I already handle that via the GoboLinux way mostly (Name/Version/ going into a central directory; this is also similar what homebrew does, and also to some extent nixos, except that they store it via a unique hash which is less elegant. For instance, on GoboLinux I would then have /Programs/Ruby/3.3.0/ - that's about as simple as can possibly be). I really don't want a tool I don't understand to inject itself here and add more complications to that. My system is already quite simple and I don't really need anything it describes to me as "you need this". I also track and handle dependencies on my own. (This is more work to do initially, but past that point I just do "ue" on the commandline to update to the latest version, where ue is simply an alias to a ruby class called UpdateEntry, which in turn updates an entry in a .yml file, which then is used to populate a SQL database and also downloads and repackages and optionally compiles/installs the given package, e. g. "ue mesa" would just update mesa .tar.xz locally. I usually don't automatically compile it though, so "ue" I just use to update a program version or simply change it; it also accepts an URL of course so users can override this behaviour as they see fit.)

It seems dotslash would complement uv well

https://dotslash-cli.com/docs/

DotSlash to get the interpreter for your platform, and uv to get the dependencies.

Perfect for corporate setups with custom mirrors etc.

uv is the best tool out there as long as you have python only dependencies. It's really fast, and you can avoid using poetry, pipenv, etc. The only reason for conda to still exist is non pythonic dependencies, but that's another beast to tackle in itself.

Am I the only one who feels like this is obviated by Docker?

uv is a clear improvement over pip and venv, for sure.

But I do everything in dev containers these days. Very few things get to install on my laptop itself outside a container. I've gotten so used to this that tools that uninstall/install packages on my box on the fly give me the heebie-jeebies.

> curl -LsSf https://astral.sh/uv/install.sh | sh

"Just pipe a random script from the internet into your shell! What could possibly go wrong?"

UV script enabled me to distribute a MCP client or server in a single file[0].

[0]: https://blog.toolkami.com/mcp-server-in-a-file/

Should I try this? I, let’s say, code with Ai and am not an engineer. Python related environment stuff makes my head explode (across the 3 computers I use). It’s the main thing my brain just can’t seem to figure out.

All these comments look like advertisement. "uv is better than python!!", "8/10 programmers recommend uv", "I was a terrible programmer before but uv changed my life!!", "uv is fast!!!"

I'm weird, this opinion Is even weirder, but how about start removing what makes Python slow? Sometimes you need yo remove features. It's hard, a pain but i dont see any other way of fixing really big mistakes...

I'm not a pythonista, and the most recent time I've been playing with python has been using octodns. origninally I was using a pip setup, and honestly wow UV was so much faster.

I'm very happy the python community has better tooling.

My go-to development environment for Python projects is nowadays Nix for uv, and uv for Python deps.

Nix does not play well with python dependencies. It's so nice to have that part taken care in a reproducible manner by uv.

I don't like that it defaults to putting the virtual environment right there, I much prefer how pipenv does it with a shared one in the users home directory, but it's a small price to pay for how fast it is.

Is there a resource to understand the nuanced technical differences between pip and uv?

As an outsider to the python ecosystem I've wanted to learn the _how_ behind uv as well, but that hasn't been immediately clear

A great step forward for those who are already locked into the language! But IMO not necessarily encouragement for newcomers to start using the language for production software.

For years I've avoided using Python tools because I've always struggled to get them working properly. Will uv solve this pain for me? Can I install a Python app globally with it?

The only reason I haven't switched, is when using uv as my environment manager, starting/connecting to the python kernel in notebooks within vscode takes forever.

I am still learning and I have the same feeling as someone who don't consider myself good with python. At least I can keep my venv in control now is all I can feel with Uv approach.

Venv seems pretty straightforward once you’ve learned the one activate command.

I don’t really get that uv solves all these problems ve never encountered. Just make a venv and use it seems to work fine.

>curl -LsSf https://astral.sh/uv/install.sh | sh

Don't do this shit, especially if you were told to do this shit.

If you are going to do this shit, separate the commands, read the bash script (and roll it down, if another file is downloaded, download that manually and inspect it).

If you are going to ask people to do this shit, split the command into two. Someone that asks me to do something insecure is either a malicious actor that is trying to compromise me, or someone careless enough to be compromised themselves.

I don't care what uv is, I can pip install stuff thank you. I install 2 or 3 things tops. I don't install 500 packages, that's sounds like a security nightmare.

Change your ways or get pwned people. Don't go the way of node/npm

p.s: Stop getting cute with your TLDs, use a .com or the TLD from your country, using gimmick TLDs is opaque and adds an unnecessary vector, in this case on the politics of the British Overseas Territory of Saint Helena, Ascension, and Tristan da Cunha.

Looks similar to buildout 15 years ago. It also made you a local executable `./bin/python`, with its own PYTHON_PATH. Then everyone rushed to virtualenv.

The popularity of uv marks the commercialization of the python ecosystem. And in this case by a company whose business model is totally elusive to me. Not a fan.

I've been using uv and am pleased that is about as useful as maven was the last time I used it 12 years ago. I'm not really sure why we still need venv.

> Can install any version of Python

Does "any" version include custom homebrew builds of Python, e.g. backports of Python 3.12 to Windows Vista/7?

I just hope that at this point the overtake over Python as a language and can shape it properly for the next 10 years(for AI and also for humans)

> uv is straightforward to install.

How do I install it globally on a system? Debian doesn't let me install packages via pip outside of a venv or similar.

Is it worth running uv inside a docker container?

Does speed really matter during python installation?

Reminds me of Julia's Pkg manager and the way Julia packages are managed (also with a .toml file). That's the way to go!

First time I tried to teach my son java, I realized how badly it's missing a built in dependency management system.

If I'm already using Poetry and not facing any issues with it, is there any advantage to using uv?

Python venv's is the #1 reason I've avoided working with it more. It used to be #2 behind strong typing, but now that Linux OSes' take up the default python install and block it from being used for quick scripts, it jumped to #1.

I've always wondered why Linux OSes that rely on python scripts don't make their own default venv and instead clobber the user's default python environment...

> On GitHub Actions, we’re planning to use uv to quickly build a Python environment and run our unit tests. In production, uv already manages Python for all of our servers.

Does that mean they aren't running unit tests _at all_ in CI yet, or they just use a totally different, newer system in production than they do for CI? Either way, brave of them to admit that in public.

Running pytest with uv run —active pytest… is very slow to get it started … anyone has some tips on this?

Is there a way to install this that doesn't involve piping a random URL to my shell interpreter?

Seems to fulfill the same role as Bundler has done in Ruby for years.

uv has made working with different python versions and environments much, much nicer for me. Most of my colleagues in computational genomics use conda, but I've yet to encounter a scenario where I've been unable to just use uv instead.

Hey have you heard about block0hunt by any chance? Looks like a cicada thing again

UV indeed is a blessing. Love it. Hopefully it gets recommended as the official one.

The best thing about uv is it's not conda.

Pip is also not conda, but uv is way faster than pip.

Huge fan of uv and ruff and starting to play around with ty. Hats of to astral!

uv brings some organization to the hell that is python package management

I find the python tooling so confusing now. There’s pip, virtualenv, pipx, uv, probably half a dozen others I’m missing. I like node, npm isolates by default, npx is easy to understand, and the ecosystem is much less fragmented. I see a python app on GitHub and they’re all listing different package management tools. Reminds me of that competing standards xkcd.

Why is it written in Rust though? I'd prefer a pure Python solution.

After I just enjoying on python project nd actually built something.

uv has definitely helped make python a first class citizen in more ways.

UV is so cool! These days, I never develop new projects without it.

I had a recent period in my programming career where I started to actually believe that the "worse is better" philosophy is true in practice. It was a dark period and thankfully the existence of tools like uv save me from that abyss.

the best thing would be to use the package manager of the os.

uv is fast enough that you can put things like this in your profile:

   alias ytd="uv tool upgrade yt-dlp && yt-dlp"

Hmpf. I am using uv now, but I have been doing fine before using poetry. For me it is not a huge revolution, as I always value reproducibility, which means lock file and checksums, and that, I was able to have before using poetry. Yes, yes, ... uv is faster. I grant them that. And yes, it's pleasant, when it runs so quickly. But I am not changing dependencies that often, that this really impacts my productivity. A venv is created, it stays. Until at some point I update pyproject.toml and the lock file.

Since I am mostly avoiding non-reproducible use-cases, like for example stating dependencies inside the python scripts themselves, without checksums, only with versions, and stuff like that, I am not really benefiting that much. I guess, I am just not writing enough throwaway code, to benefit from those use-cases.

Some people here act, like uv is the first tool ever to install dependencies like npm and cargo and so on. Well, I guess they didn't use poetry before, which did just that.

best thing would be to use the package manager of the os.

I don't know. This looks more complex than pyenv.

uv has been my sole reason to come back to Python for coding. It was just too time consuming to setup a working dev environment with Python locally.

How is this different than (or better than) pyenv?

Hype is dangerous

So basically a node-like thing for python

Finally, npm comes to python-land. :-)

Am I the only one who thought poetry was still the greatest available whizbang?

Has been a life changer for me.

the farce that is python packaging is the reason that 99% of docker images exist

Seeing a `pip install -r requirements.txt` in a very recently created python project is almost a red flag now...

why uv is not included by default with the standard Python binary installers?

Mojo?

the hilarious part is that uv is written in rust

sunlight really IS the best disinfectant

why is a uv README the top post on HN??

And Rust is the best thing to happen to CS in a decade

Honestly though it's a pretty rough indictment of Python that the best thing to happen in a decade is that people started writing Python tools in Rust. Not even a little Rust, uv is 98% Rust. I mean, they just released 3.14 and that was supposed to be a pretty big deal.

uv is spectacular

But I’m utterly shocked that UV doesn’t support “system dependencies”. It’s not a whole conda replacement. Which is a shame because I bloody hate Conda.

Dependencies like Cuda and random C++ libraries really really ought to be handled by UV. I want a true genuine one stop shop for running Python programs. UV is like 80% of the way there. But the last 20% is still painful.

Ideally UV would obsolete the need for docker. Docker shouldn’t be a requirement to reliable run a program.

Wait until they fully embrace the benefits of strong typing :)

nix-shell is the OG

There is something hilarious about using a project/package manager written in another language.

Another year, another new way of installing python packages?

yes

[dead]

ffs, stop installing stuff by piping random scripts from the internet to shell!!1one

[dead]

[flagged]

[flagged]

Another Python package manager? How many are there now?

May I ask whether I can obtain the product I want by describing it directly?

A problem remain in that many and still more of the popular repositories don't use uv to manage their dependencies.

So you are back having to use conda and the rest. Now, you have yet another package manager to handle.

I wouldn't be harsh to engineers at astral who developed amazing tooling, but the issue with the python ecosystem isn't lack of tooling, it is the proliferation and fragmentation. To solve dependency management fully would be to incorporate other package descriptors, or convert them.

Rsbuild, another rust library, for the node ecosystem did just that. For building and bundling. They came up with rspack, which has large compatibility with the webpack config.

You find a webpack repo? Just add rsbuild, rspack, and you are pretty much ready to go, without the slow (node native) webpack.