I highly, highly recommend uv. It solves & installs dependencies incredibly fast, and the CLI is very intuitive once you've memorized a couple commands. It handles monorepos well with the "workspaces" concept, it can replace pipx with "uv tool install," handle building & publishing, and the docker image is great, you just add a FROM line to the top and copy the bin from /uv.

I've used 'em all, pip + virtualenv, conda (and all its variants), Poetry, PDM (my personal favorite before switching to uv). Uv handles everything I need in a way that makes it so I don't have to reach for other tools, or really even think about what uv is doing. It just works, and it works great.

I even use it for small scripts. You can run "uv init --script <script_name.py>" and then "uv add package1 package2 package3 --script <script_name.py>". This adds an oddly formatted comment to the top of the script and instructs uv which packages to install when you run it. The first time you run "uv run <script_name.py>," uv installs everything you need and executes the script. Subsequent executions use the cached dependencies so it starts immediately.

If you're going to ask me to pitch you on why it's better than your current preference, I'm not going to do that. Uv is very easy to install & test, I really recommend giving it a try on your next script or pet project!

The script thing is great. By the way those 'oddly formatted' comments at the top are not a uv thing, it's a new official Python metadata format, specifically designed to make it possible for 3rd party tools like uv to figure out and install relevant packages.

And in case it wasn't clear to readers of your comment, uv run script.py creates an ephemeral venv and runs your script in that, so you don't pollute your system env or whatever env you happen to be in.

I generally agree but one thing I find very frustrating (i.e. have not figured out yet) is how deal with extras well, particularly with pytorch. Some of my machines have GPU, some don't and things like "uv add" end up uninstalling everything and installing the opposite forcing a resync with the appropriate --extra tag. The examples in the docs do things like CPU on windows and GPU on Linux but all my boxes are linux. There has to be a way to tell it that "hey I want --extra GPU" always on this box. But I haven't figured it out yet.

Getting the right version of PyTorch installed to have the correct kind of acceleration on each different platform you support has been a long-standing headache across many Python dependency management tools, not just uv. For example, here's the bug in poetry regarding this issue: https://github.com/python-poetry/poetry/issues/6409

As I understand it, recent versions of PyTorch have made this process somewhat easier, so maybe it's worth another try.

It sounds like you’re just looking for dependency groups? uv supports adding custom groups (and comes with syntactic sugar for a development group

I'm not sure if I got your issue, but I can do platform-dependent `index` `pytorch` installation using the following snippet in `pyproject.toml` and `uv sync` just handles it accordingly.

[tool.uv.sources] torch = [{ index = "pytorch-cu124", marker = "sys_platform == 'win32'" }]

Does this help? https://github.com/astral-sh/uv/pull/7851

i use uv+torch+cuda on linux just fine,never used the extra flag, i wonder what's the problem here?

Getting something that works out of the box on just your computer is normally fine. Getting something that works out of the box on many different computers with many different OS and hardware configurations is much much harder.

I didn't know that UV would now edit the script for you. That is just icing on the cake!

For the curious, the format is codified here: https://peps.python.org/pep-0723/

The install speed alone makes it worthwhile for me. It went from minutes to seconds.

I was working on a Raspberry Pi at a hackathon, and pip install was eating several minutes at a time.

Tried uv for the first time and it was down to seconds.

Can confirm this is all true. I used to be the "why should I switch" guy. The productivity improvement from not context switching while pip installs a requirements file is completely worth it.

I happened to use uv recently for a pet project, and I totally agree with you. It's really really good. I couldn't believe its dependency resolution and pulling can be so fast. Imho, it's the python package manager (I don't know the most suitable name to categorize it) done right, everything just works, the correct way.

As a person who don’t work often on python code but occasionally need to run server or tool I find UV blessing. Before that I would beg people to help me just not to figure out what combination of obscure python tools I need. Now doing “uv run server.py” usually works.

That scripting trick is awesome! One of the really nice things about Elixir and its dependency manager is that you can just write Mix.install(…) in your script and it’ll fetch those dependencies for you, with the same caching you mentioned too.

Does uv work with Jupyter notebooks too? When I used it a while ago dependencies were really annoying compared to Livebook with that Mix.install support.

uv offers another useful feature for inline dependencies, which is the exclude-newer field[1]. It improves reproducibility by excluding packages released after a specified date during dependency resolution.

I once investigated whether this feature could be integrated into Mix as well, but it wasn't possible since hex.pm doesn't provide release timestamps for packages.

> Does uv work with Jupyter notebooks too?

Yes![2]

[1] https://docs.astral.sh/uv/guides/scripts/#improving-reproduc... [2] https://docs.astral.sh/uv/guides/integration/jupyter/

> It solves & installs dependencies incredibly fast

If you are lucky, and you don't have to build them, because the exceptionally gifted person who packaged them didn't know how to distribute them and the bright minds running PyPI.org allowed that garbage to be uploaded and made it so pip would install that garbage by default.

> can replace pipx with "uv tool install,"

That's a stupid idea. Nobody needed pipx in the first place... The band-aid that was applied some years ago is now cast in stone...

The whole idea of Python tools trying to replace virtual environment, but doing it slightly better is moronic. The virtual environments is the band-aid. It needs to go. The Python developers need to be pressured into removing this garbage, and instead working on having program manifests or something similar. Python has virtual environments due to incompetence of its authors and unwillingness to make things right, once that incompetence was discovered.

----

NB. As it stands today, if you want to make your project work well, you shouldn't use any tools that install packages by solving dependencies and downloading them from PyPI. It's not the function of the tool doing that, it's the bad design of the index.

The reasonable thing to do is to install the packages (for applications) you need during development, figure out what you actually need, and then store the part you need for your package to work locally. Only repeat this process when you feel the need to upgrade.

If you need packages for libraries, then you need a way to install various permutations within allowed versions: no tool for package installation today knows how to do it. So, you might as well not use any anyways.

But, the ironic part is that nobody in Python community does it right. And that's why there are tons of incompatibilities, and the numbers increase dramatically when projects age even slightly.

Ohhh watch out we have a misunderstood genius here

Uv really fixes Python. It takes it from "oh god I have to fight Python again" to "wow it was actually fast and easy".

I think all the other projects (pyenv, poetry, pip, etc.) should voluntarily retire for the good of Python. If everyone moved to Uv right now, Python would be in a far better place. I'm serious. (It's not going to happen though because the Python community has no taste.)

The only very minor issue I've had is once or twice the package cache invalidation hasn't worked correctly and `uv pip install` installed an outdated package until I `uv clean`ed. Not a big deal though considering it solves so many Python clusterfucks.

Agree. I mostly do front end in my day job, and despite JavaScript being a bit of a mess lang, dealing with npm is way better than juggling anaconda, miniforge, Poetry, pip, venv, etc depending on the project.

UV is such a smooth UX that it makes you wonder how something like it wasn’t part of Python from the start.

+1

…but we did have to wait for cargo, npm (I include yarn and pnpm here) and maybe golang to blaze the ‘this is how it’s done’ trail. Obvious in hindsight.

Ruby's bundler had already invented the correct model many years ago. It only took time for others to accept that.

Yeah, but unlike bundle, uv locks in your Python version and downloads that Python version as needed. It’s like bundle and rbenv combined.

Sure. That seems less important to me than the packages. As long as the language version is checked, that’s the important bit.

Wait, a bundler? What needs to be bundled when using Ruby? Maybe this is not the same meaning as with JS bundlers. And why does a bundles manage dependencies?

It’s what it’s called https://bundler.io/

No sillier than the other various package managers.

Feels like you're doing it wrong if you're dealing with all of those.

More importantly, migrating from npm, to pnpm, to yarn, to bun, is very nearly seamless. Migrating in the Python ecosystem? Not anywhere close.

You mean off the job you have to juggle all those tools? On the job that would be kind of crazy, to allow every project its own tool chain.

True.

I had to give up on mypy and move to pyright because mypy uses pip to install missing types and they refuse to support uv. In the CI pipeline where I use UV, I don't have a pip installed so mypy complains about missing pip.

Of course I can do it by myself by adding typing pkgs to requirement.txt file then what's the point of devtools! And I don't want requirements.txt when I already got pyproject.toml.

Once you get used to cargo from rust, you just can't tolerate shitty tooling anymore. I used to think pip was great (compared to C++ tooling).

Pyright is waaay better than Mypy anyway so I'd say they did you a favour.

Uv doesn't fix anything. The fixing that Python needs is the removal of the concept of virtual environments and fixing the import and packaging systems instead.

The only thing it does, it makes bad things happen faster. Who cares...

I think their only big gap is the inability to alias general project non-python scripts in uv. This forces you to use something like a justfile or similar and it would be much more ergonomic to just keep it all in uv.

uv belongs to a startup. They will surely introduce some wacky monetisation scheme sooner or later.

I wouldn't get too used to it.

Strong agree. The respectful act of other package managers would be consider themselves deprecated and point to uv instead.

The risk is obviously uv losing funding. I kinda hope the PSF has thought about this and has a contingency plan for uv winning and dying/becoming enshittified soon after.

If they never made any plan about how modules are installed and there is no official way… i doubt they made a plan about uv.

Which companies run heavily (either solely or huge parts) run on Python? They should take initiative and start blogging.

I totally disagree. Having a single vendor with that much power is a bad idea. If the PSF were able to focus on tooling rather than their current focus, they would be great stewards of this sort of thing. Sadly I doubt that will happen, in which case I think many options is the best approach.

I have been using Python for 20 years, and have been an intermediate to advanced user of it for last 5-7 years. I use it mostly for scientific computing (so lots of Numpy, SciPy, etc.), IoT data processing, and also for some microservices that don’t need to be super fast. I publish and maintain a few packages in PyPI and conda (though I almost never use conda myself), including a C++ library with Python bindings generated by SWIG (SWIG wouldn’t be my first choice, but I inherited it).

In what I’ve done, I’ve never found things like pipenv, let alone uv, to be necessary. Am I missing something? What would uv get?

I am pretty happy with poetry for near future. I prefer using python interpreters installed by linux package manager. In cloud I use python docker. Poetry recently added option to install python too if I changed my mind.

I have already setup CI/CD pipelines for programs and python libraries. Using uv would probably save some time on dependency updates but it would require changing my workflow and CI/CD. I do not think it is worth the time right now.

But if you use older environments without proper lock file I would recommend switching immediately. Poetry v2 supports pyproject.toml close to format used by uv so I can switch anytime when it would look more appealing.

Another thing to consider in long term is how astral tooling would change when they will need to make money.

> I prefer using python interpreters installed by linux package manager.

uv will defer to any python it finds in PATH as long as it satisfies your version requirements (if any):

https://docs.astral.sh/uv/concepts/python-versions/

It also respects any virtual environment you've already created, so you can also do something like this:

   /usr/bin/python3 -m venv .venv
   .venv/bin/pip install uv
   .venv/bin/uv install -r requirements.txt # or
   .venv/bin/uv run script ...

It's a very flexible and well thought out tool and somehow it manages to do what I think it ought to do. I rarely need to go to its documentation.

> Using uv would probably save some time on dependency updates but it would require changing my workflow and CI/CD.

I found it very straightforward to switch to uv. It accommodates most existing workflows.

I'm pretty much with you and still trying to figure out why I want to switch away from pyenv+poetry.

I get that uv does both, but I'm very happy with pyenv+poetry combo.

Old baggage, but I came from the rvm world which attempted to do exactly what uv does, but rvm was an absolute mess in 2013. rbenv+bundler solved so many problems for me and the experience was so bad that when I saw uv my gut reaction was to say "never again".

But this thread has so many praises for it so one day maybe i'll give it a try.

Uv dependency solving is light years faster than poetry. If you are working on actual projects with many dependencies, poetry is a liability

UV is such a big improvement that it moves Python from my "would use again if I had to, but would really not look forward to it" pile to my "happy to use this as needed" pile. Without disparaging the hard work by many that came before, UV shows just how much previous tools left unsolved.

For scripting... HIGHLY recommend putting your dependencies inline.

E.g.:

  #!/usr/bin/env python3
  # /// script
  # requires-python = ">=3.11"
  # dependencies = [
  #     "psycopg2-binary",
  #     "pyyaml",
  # ]
  # ///

Then -

  uv run -s file.py

Do you need a wrapper script for scripts in the PATH or execve? I would usualy chmod+x the script but I am not sure here.

If you want to make it work regardless of where uv is installed, you can use the following shebang line:

  #!/usr/bin/env uv run --script

Not at a laptop to try this right now, but shouldn't this be possible with the shebang? Something along the lines of:

    #!/home/tetha/Tools/uv run

Yes it is, I just converted my work scripts over this afternoon.

    #!/usr/bin/env uv run

How does this interact with your code editor or IDE? When you edit the file, where does the editor look for information about the imported third-party libraries?

Usually the VENV and import lines are enough

How do you determine where the venv is? AFAIK, uv run in script mode creates the venv in some random temporary directory.

For my use cases, uv is so frictionless it has effectively made Python tolerable for me. I primarily discovered it via Simon Willison's (@simonw) blog posts[1]. I recommend his blog highly.

1. https://simonwillison.net/tags/uv/

I'm using exclusively uv for personal projects - and small prototypes at work - and I can't recommend it enough.

Uv makes python go from "batteries included" to "attached to a nuclear reactor"

i’ve started slipping uv into production work projects along with an auto generated requirements.txt for anyone who doesn’t wanna use uv. hoping i can drive adoption on my team while still leaving an alternative for people who don’t wanna use it

You mean `uv pip compile pyproject.toml > requirements.txt`?

I switched to hatch last year for many projects, its been quite pleasant.

Has anyone used both hatch and uv, and could comment on that comparison?

EDIT: quick google gives me these opinions[1]

[1]: https://www.reddit.com/r/Python/comments/1gaz3tm/hatch_or_uv...

I dabble with python occasionally and I'm always fighting with tools and tool combinations that don't really combine well. The last time I settled on using conda to get some isolation of python versions and then pipenv for getting some sane package management with a lock file. Not pretty but it kind of worked. Except I had a hard time convincing vs code and pycharm of the correct environment with that combination (couldn't resolve libraries I installed). I got it working eventually but it wasn't a great experience.

It sounds like uv should replace the combination. Of course there is the risk of this being another case of the python community ritually moving the problem every few years without properly solving it. But it sounds like uv is mostly doing the right thing; which is making global package installation the exception rather than the default. Most stuff you install should be for the project only unless you tell it otherwise.

Will give this a try next time I need to do some python stuff.

Do. I was sceptical at first - exactly because of the points you make: I mostly do ML, so for getting PyTorch and Cuda etc. to play nice conda was basically my go-to.

We use poetry at work, but getting it to play nice with PyTorch is always a bit of an art. I tried to get into Pixi, but have been a little annoyed as it seems to have inherited conda's issues when mixing conda and PyPi.

uv so far has been relatively smooth sailing, and they even have an entire section on using it with PyTorch: https://docs.astral.sh/uv/guides/integration/pytorch/

I recently switched our Python projects to uv and it love it. It just does everything and is really fast (this just cannot be underestimated in what it means for your workflow).

I've tried almost every Python packaging solution under the sun in the past 15 years but they all had their problems. Finally I just stuck with pip/pip-tools and plain venv's but strung together with a complicated Makefile to optimize the entire workflow for iteration speed (rebuilding .txt files when .in requirements changes, rebuilding venv if requirements change, etc). I've been able to reduce it to basically one Make target calling uv to do it all.

Ans you can now install Python and set it to the default in your path with the --default flag. Big plus for me to replace pyenv finally.

finally! this was the thing keeping me from switching every time i looked into it.

I want to switch to uv from pyenv but one use case that didn't manage to figure out is if I can have similar setup like pyenv that I install few python version and setup one to be a global default (configured in zsh). I know for bigger projects proper way is to setup virtual environment for all new project but I do many mini (throwaway) python scripts and experiments or testing repos in python and would be really annoying to setup environment for those - so far pyenv worked well for me for such cases without having pretty much dependency conflicts.

Yes, uv is well suited to that use case by declaring your Python version and/or dependencies right in the script itself:

https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...

You can use an alternate shebang line so you can run the script directly:

  #!/usr/bin/env -S uv run --script
  # /// script
  # requires-python = ">=3.12"
  # dependencies = [
  #   "requests",
  #   "typer-slim",
  # ]
  # ///
  import requests
  import typer
  # ...

I used to have the same setup - a global tools venv with some useful dependencies.

Uv takes the position that since it’s so fast to install dependencies and create environments, you don’t maintain a global venv.

  uvx ruff file.py

Will setup a venv, install ruff into it, and run over your file. https://docs.astral.sh/uv/guides/tools/

Otherwise you can:

  uv run —-with package file.py

If you don’t want to declare your dependencies.

https://docs.astral.sh/uv/guides/scripts/#running-a-script-w...

How about just install a python version with uv and install everything into that?

Or better, do the above, then create a virtual env, set the virtual env in your.bashrc and install everything into that

Better still... use uv script --init See other comments on this post

15 year Python dev who usually adopts tooling slowly. Just do it, uv's absolutely worth it.

I also use mise with it, which is a great combination and gives you automatic venv activation among other things.

See, among other mise docs related to Python, https://mise.jdx.dev/mise-cookbook/python.html

See also a Python project template I maintain built on mise + uv: https://github.com/level12/coppy

ideally mise could be replaced entirely by uv or at least just be a thin wrapper around uv (in some ways that's already the case), but given this article requires the use of the custom uv-python-symlink utility it seems uv isn't quite there yet

Mise does way more than uv, it's a much larger scope than just Python tooling.

I think the current status quo, that of mise utilizing uv for it's Python integration support, makes sense and I don't see that changing.

Also, FWIW, mise has other methods for Python integration support, e.g. pyenv, virtualenv, etc.

Edit:

Ha... Didn't realize who I was replying to. Don't need me to tell you anything about mise. I apparently misinterpreted your comment.

the reality that I'm sure you've heard me say many times is that I'm just not a python dev and astral is likely always going to build a better solution around python than I ever could. They've just focused a lot more on the package manager side of things than the runtime/venv management side so far but I suspect that will change—and given astral's velocity I doubt we'll be waiting long

and btw mise's venv support isn't going anywhere probably ever, but I do hope that at some point we could either let uv do the heavy lifting internally or point users to uv as a better solution

I used to install Python through mise but now I just use uv tbh.

Similar. But we get other benefits through mise, like tasks and other tool installs (e.g. Terraform). So we still use them together.

That's fair, it's also nice if you have a backend in Python and a frontend in JS since mise also handles node.

Forgot about that! Yes, another significant benefit of why we use mise.

In particular, we use flask-vite and it's so nice to be able to have the right version of Node specified in the same management system as we specify the Python version. This solved a not insignificant amount of angst around FE development for me personally since I spend most of my time in the BE.

It's not like it was insurmountable before. But now, with mise, it's in that "just works" category for me.

100% agreed, it just takes a task that was a 10-15min setup depending on your environment and personal knowledge to a 2min thing. It just makes life easier and it puts the bar for starting lower, a win in my book =)

Uv in script mode has made me love python again.

Maybe this one will finally be adopted as the official package manager for Python? Only 20 years late, but it would be a nice development.

Please not. Python core is suffering from corporate capture and ruins everything it touches.

The PSF would probably dig up some old posts from the uv authors, defame them, take the code and make it worse.

Pfft. Pull the other one. The PSF hates the idea of dealing with something so icky.

I have been pretty pleased with uv, but I am continually worried about the funding model. What happens when the VC starts demanding a return?

We fork it. Whatever carrot the VC's dangle can be chased by the handful who care, and the rest of us can continue using the important part.

Ah, so that's why it's written in Rust. Less people who care about Python packaging are capable of forking it.

I converted along with most of the people in this thread.

IMO no really hard problem is ever truly solved but as can be seen in other comments, this group of people really crushed the pain of me and *many* others, so bravo alone on that - you have truly done humanity a service.

I love using it. I'm concerned that they go the route of Terraform and put in play pricing and values that differ from what their users support.

> Maybe I installed some other things for some reason lost in the sands of time.

FWIW, I was able to confirm that the listed primary dependencies account for everything in the `pip freeze` list. (Initially, `userpath` and `pyrsistent` were missing, but they appeared after pinning back the versions of other dependencies. The only project for which I couldn't get a wheel was `python-hglib`, which turned out to be pure Python with a relatively straightforward `setup.py`.)

I decided to give uv a shot on my new machine over pyenv and I've been enjoying it. Just last week I had to generate out 90 slides from some data last minute. Quickly created a project added in my dependencies (pandas, matplotlib, python-pptx), then crunched out some code. Absolutely zero friction with a much easier to use set of commands in my opinion.

has anybody doing complex projects achiever success with uv completely replacing pyenv, and had mostly pros and few or no cons?

I'm very comfortable with pyenv, but am extremely open to new stuff

Sure, I've basically replaced pyenv, pyenv-virtualenv, poetry; with uv. I can't think about cons personally, though you might need to dig into the docs at times.

Teaching a course for a corporate client this week for data scientists. The first day (of five) we covered uv. Minds blown.

"Course was worth it just for uv"

I've used uv to work on the feast feature store project to great success

I don't know how complex your project is but I moved my previous work from pyenv to rye(UV and rye have merged, most work is being done on uv, today I'd probably use UV)

And am currently trying to move current work to UV. The problems seem to be possibility of unknown breakage for unknown users of the old project not any known technical issue.

I'd highly reccomend UV. Its just easier/more flexible. And it downloads third party pre compiled python builds instead of the extra time and complexity to get it compiling locally. Its much nicer especially when maintaing an environment for a team that just works without them having to know about it

One downside of UV is that unlike pyenv and rye it doesn't shim python. Pyenv shim did give me some trouble but rye simples shim didn't. The workaround is to run stuff with uv run x.py instead of python x.py

`uv tool install` will create shims in .local/bin

I worked in a large-ish org where 20+ python projects, their CI/CD pipelines and their docker images were migrated from `pyenv` + `.python-version` + `requirements.txt` to `uv` in basically a single day.

If you are comfortable with `pyenv`, the switch to `uv` is basically a walk in the park. The benefit is the speed + the predictable dependencies resolution.

I’m enjoying UV a lot as well. If anyone from the Astral team sees this, I’d love to request more functionality or examples around packaging native libraries.

At this point, just thinking about updating CIBuildWheel images triggers PTSD—the GitHub CI pipelines become unbearably slow, even for raw CPython bindings that don’t require LibC or PyBind11. It’s especially frustrating because Python is arguably the ultimate glue language for native libraries. If Astral’s tooling could streamline this part of the workflow, I think we’d see a significant boost in the pace of both development & adoption for native and hardware-accelerated tools.

Are people seeing it work well in GPU/pydata land and creating multiplatform docker images?

In the data science world, conda/mamba was needed because of this kind of thing, but a lot of room for improvement. We basically want lockfile, incremental+fast builds, and multi-arch for these tricky deps.

It works transparently. The lock file is cross-platform by default. When using pytorch, it automatically installs with MPS support on macOS and CUDA on Linux; everything just works. I can't speak for Windows, though.

Works better than poetry for cuda-versioned pytorch. I don't have overlap with your other domains unfortunately (ML, not data science).

Thanks!

I think the comparison for data work is more on conda, not poetry. afaict poetry is more about the "easier" case of pure-python, and not native areas like prebuilt platform-dependent binaries. Maybe poetry got better, but I typically see it more like a nice-to-have for local dev and rounding out the build, but not that recommended install flow for natively-aligned builds.

So still curious with folks navigating the 'harder' typical case of the pydata world, getting an improved option here is exciting!

uv is excellent! The only think I'm missing is an easy way to update all packages in an env, something like `uv update --all` or `uv update plotly`.

Which would fit in with existing uv commands[1] like `uv add plotly`.

There is an exisiting `uv lock --upgrade-package requests` but this feels a bit verbose.

[1]: https://docs.astral.sh/uv/guides/projects/#creating-a-new-pr...

If uv figures out a way to capture the scientific community by adding support for conda-forge that'll be the killshot for other similar projects, imo. Pixi is too half-baked currently and suffers from some questionable design decisions.

Out of curiosity, which design decisions do you find questionable and what do you feel is half-baked with Pixi? It's been working well for us.

which subfield of scientific community uses that? and for what purpose, if you could summarize

The key thing of conda-forge is that it's language (rust/go/c++/ruby/java/...) and platform (linux/macos/win/ppc64le/aarch64/...) agnostic rather than being python only.

If you want you can depend on a C++ and fortran compiler at runtime and (fairly) reliably expect it to work.

This makes sense for people keen on pyenv.

I'm still very keen on virtualenvwrapper, I hope that the fast dependency resolution and install of uv can come there and to poetry.

Is there a guide for how to use uv if you're a JS dev coming from pnpm?

I just want to create a monorepo with python that's purely for making libraries (no server / apps).

And is it normal to have a venv for each library package you're building in a uv monorepo?

If the libraries are meant to be used together, you can get away with one venv. If they should be decoupled, then one venv per lib is better.

There is not much to know:

- uv python install <version> if you want a particular version of python to be installed

- uv init --vcs none [--python <version>] in each directory to initialize the python project

- uv add [--dev] to add libraries to your venv

- uv run <cmd> when you want to run a command in the venv

That's it, really. Any bonus can be learned later.

There's also workspaces (https://docs.astral.sh/uv/concepts/projects/workspaces/) if you have common deps and it's possible to act on a specific member of the workspace as well.

That's one of the bonus I was thinking about. It's nice if you have a subset of deps you want to share, or if one dep is actually part of the monorepo, but it does require more to know.

Thanks. Why is the notion of run and tool separate? Coming from JS, we have the package.json#scripts field and everything executes via a `pnpm run <script name>` command.

Tool ?

Maybe you mean uv tool install ?

In that case it's something you don't need right now, uv tool is useful, but it's a bonus. It's to install 3rd party utilities outside of the project.

There is no equivalent to script yets, althought they are adding it as we speak.

uv run exec any command in the context of the venv (which is like a node_modules), you don't need to declare them prior to calling them.

e.g: uv run python will start the python shell.

uv sync if you clone a github repo

uv run in the freshly cloned repo will create the venv and install all deps automatically.

You can even use --extra and --group with uv run like with uv sync. But in a monorepo, those are rare to use.

Thanks for the info.

I looked at the group documentation, but it's not clear to me why I would want to use it, or where I would use it:

https://docs.astral.sh/uv/concepts/projects/layout/#default-...

(I'm a JS dev who has to write a set of python packages in a monorepo.)

sync is something you would rarely use, it's most useful for scripting.

uv run is the bread and meat of uv, it will run any command you need in the project, and ensure it will work by synching all deps and making sure your command can import stuff and call python.

In fact, if you run a python script, you should do uv run python the_script.py,

It's so common uv run the_script.py will work as a shortcut.

I will write a series of article on uv on bitecode.dev.

I will write it so that it work for non python devs as well.

I wasn’t able to figure how to make a uv installed python version a global when “python” is called, at least in the current shell, as I need it in CI.

That feature's in preview now. You can run it like:

  uv python install --preview --default 3.13

and then you get Python 3.13 whenever you run `python` outside of an environment that declares something else.

This is great news. I had hacked together some bash and fish scripts to mostly do this but they still had some rough edges. I missed that uv now had this ready for preview

I just found that a couple weeks ago.

I'm an end user, too. I don't have anything to do with uv development. I stumbled across it in a GitHub issue or something and passed along the info.

Thank you!! Will try it tomorrow.

You bet. I was so happy to find that!

How does this compare to Mise: https://mise.jdx.dev/lang/python.html ?

mise is higher level. i use it to install uv in projects with other non-python dependencies (helm, terraform, npm), which i also install with mise.

Then all the python dependencies are managed with uv.

For a non-python project which needs a python-based CLI tool, i’m not sure if i’d use mise or uv (uvx).

Note that despite the title, the author is not switching from pyenv to uv, but from pip, pyenv, pipx, pip-tools, and pipdeptree to uv, because uv does much more than pyenv alone.

It replaces a whole stack, and does each feature better, faster, with fewer modes of failure.

I've stuck with simple tools for all these years: pip, pip-tools, virtualenvwrapper etc. I've tried other stuff like poetry and it's always seemed like hard work. I'm glad I waited for uv. The one thing I wish it supported is having venvs outside of project directories. It's so much nicer to have them all in one place (like ~/.venvs or something) which you can ignore for backups etc. That's the only thing I miss, though.

I'm also only missing virtualenvwrapper-like support for central named venvs in uv.

I'm too used to type virtualenvwrapper's `workon` and `mkvirtualenv` commands, so I've written some lightweight replacement scripts of virtualenvwrapper when using uv. Supports tab completion and implements only the core functionality of virtualenvwrapper:

https://github.com/sitic/uv-virtualenvwrapper

What does uv offer over bog-standard setuptools, pip, pip-tools, and build?

Right now, the only thing I really want is dependency pinning in wheels but not pyproject.yaml, so I can pip install the source and get the latest and greatest, or I can pip install a wheel and get the frozen dependencies I used to build the wheel. Right now, if I want the second case, I have to publish the requirements.txt file and add the wheel to it, which works but is kind of awkward.

It does everything with less surprises and faster. Just try it.

So... I am switching a project from pip to uv. I am hoping for things to be "better", but so far it's been a bit of a familiar "why does it not work as described?" journey.

Could you give some detail on things you've found that still don't work as described?

I could use more guidance on migration for setups where development and testing is using Docker. I figured things out eventually. The issue here is lack of good tutorials that cover cases other than a happy path.

> I figured things out eventually. The issue here is lack of good tutorials that cover cases other than a happy path.

I'd like to encourage you to blog about it, then.

Because pyenv compiles from source, it's optimized for your own platform. In practice, are these performance differences noticeable?

Hi! I work on the Python distributions uv uses. Performance is really important to us and we're on the bleeding edge of performant Python builds. Our distributions use profile guided optimization (PGO) as well as post-link optimizations (BOLT). From my understanding, these are not enabled by pyenv by default because they significantly increase build times. It's possible there are some platform-specific build benefits, but I'd be surprised if it was significant.

I can set up some benchmarks comparing to pyenv on a couple common platforms – lately I've just been focused on benchmarking changes to CPython itself.

For what it's worth, I didn't notice a difference between my distro-provided Python 3.12 and the one I built from source - and enabling profile-guided optimization made only a slight difference. I haven't tested with the precompiled versions uv uses, so they could be slower for some reason, but I doubt it. On the other hand, my hardware is rather old, so maybe newer machines allow for significant optimizations that the system version wouldn't have. But I still kinda doubt it.

If performance is important to you, the ancient advice to profile bottlenecks and implement important parts in C where you can, still applies. Or you can try other implementation like PyPy.

frankly the only pain point i have working with uv is that it's too new for the LLMs to know about it

What do LLMs have to do with package and project management?

Some people are too lazy to read docs, so they ask the bullshit generators instead.

The functionalities of three tooling projects, namely uv, ruff (linter), and pyright (type checker) need to merge and become mandatory for new Python projects. Together they will bring some limited sanity to Python.

Ruff is already integrated into uv and Astral are working on type checker.

How is ruff integrated? As far as I understand, it's still a separate tool that you need to install.

i believe there is a type checker branch on ruff git

Currently known as red-knot:

https://github.com/astral-sh/ruff/milestone/20

What benefit does merging provide?

In an ideal world they shouldn't have to, but in the real world, it makes it easier for enterprises to adopt without friction. Adopting three tools is a threefold bigger challenge in enterprises, but thinking about it as a single tool makes it more amenable to enterprise adoption where it's needed the most. The merging I suggest is only logical, more like a bundling.

Hmmm, I've never seen that and I feel like I work with some pretty locked down companies.