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 " and then "uv add package1 package2 package3 --script ". 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 ," 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.

uv actually handles thr issues described there very well (uv docs have have a page showing a few ways to do it). The issue for me is uv has massive amnesia about which one was selected and you end up trashing packages because of that. uv is very fast at thrashing though so it's not as bad as if poetry were thrashing.

I end up going to the torch website and they have a nice little UI I can click what I have and it gives me the pip line to use.

That's fine if you are just trying to get it running on your machine specifically, but the problems come in when you want to support multiple different combinations of OS and compute platform in your project.

On nvidia jetson systems, I always end up compiling torchvision, while torch always comes as a wheel. It seems so random.

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

It is... but basically it need to remember which groups are sync'd. For example if you use an extra, you have to keep track of it constantly because sync thrashes around between states all the time unless you play close and tedious attention. At least I haven't figured out how to make it remember which extras are "active".

    uv sync --extra gpu
    uv add matplotlib # the sync this runs undoes the --extra gpu
    uv sync # oops also undoes all the --extra

What you have to do to avoid this is to remember to use --no-sync all the time and then meticulously manually sync while remembering all the extras that I do actually currently want:

    uv sync --extra gpu --extra foo --extra bar
    uv add --no-sync matplotlib
    uv sync --extra gpu --extra foo --extra bar

It's just so... tedious and kludgy. It needs an "extras.lock" or "sync.lock" or something. I would love it if someone tells me I'm wrong and missing something obvious in the docs.

To make the change in your environment:

1. Create or edit the UV configuration file in one of these locations:

- `~/.config/uv/config.toml` (Linux/macOS)

- `%APPDATA%\uv\config.toml` (Windows)

2. Add a section for default groups to sync:

```toml

[sync]

include-groups = ["dev", "test", "docs"] # Replace with your desired group names

```

Alternatively, you can do something similar in pyproject.toml if you want to apply this to the repo:

```toml

[tool.uv]

sync.include-groups = ["dev", "test", "docs"] # Replace with your desired group names

```

Thank you! That's good to know. Unfortunately it doesn't seem to work for "extras". There may be some target other than sync.include-groups but I haven't found it yet.

What I am struggling with is what you get after following the Configuring Accelerators With Optional Dependencies example:

https://docs.astral.sh/uv/guides/integration/pytorch/#config...

Part of what that does is set up rules that prevent simultaneously installing cpu and gpu versions (which isn't possible). If you use the optional dependencies example pyproject.toml then this is what happens:

    $ uv sync --extra cpu --extra cu124
    Using CPython 3.12.7
    Creating virtual environment at: .venv
    Resolved 32 packages in 1.65s
    error: Extras `cpu` and `cu124` are incompatible with the declared conflicts: {`project[cpu]`, `project[cu124]`}

And if you remove the declared conflict, then uv ends up with two incompatible sources to install the same packages from

    uv sync --extra cpu --extra cu124
    error: Requirements contain conflicting indexes for package `torch` in all marker environments:
    - https://download.pytorch.org/whl/cpu
    - https://download.pytorch.org/whl/cu124

After your comment I initially thought that perhaps the extras might be rewritten as group dependencies somehow to use the ~/.config/uv/config.toml but according to the docs group dependencies are not allowed to have conflicts with each other and must be installable simultaneously (makes sense since there is an --all-groups flag). That is you must be able to install all group dependencies simultaneously.

You can control dependencies per platform

https://docs.astral.sh/uv/concepts/projects/dependencies/#pl...

Not sure if it's as granular as you might need

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

Unfortunately it didn't seem to help

https://news.ycombinator.com/threads?id=fluidcruft#43355636

I haven't tried it yet but that looks like exactly what I've been missing.

This happened to me too, that is why I stopped using it for ML related projects and stuck to good old venv. For other Python projects I can see it being very useful however.

Some Windows machines have compatible GPUs while others don't, so this doesn't necessarily help. What is really required is querying the OS for what type of compute unit it has and then installing the right version of an ML library, but I'm not sure that will be done.

Even without query, just setting an environment variable or having remember which extras are already applied to the already synced .venv some way.

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.

Why would you be redoing your venv more than once?

Once rebuilding your venv takes negligible time, it opens up for all kinds of new ways to develop. For example I now always run my tests in a clean environment, just to make sure I haven't added anything that only happens to work in my dev venv.

I thought you wanted to test your program, but seems you want to make sure that your unzip library keeps working :D

That's smart. Oh, you used `pip install` to fix a missing import, but forgot to add it to pyproject.toml? You'll find out quickly.

It has nothing to do with redoing venv: some package installs were just taking multiple minutes.

I cancelled one at 4 minutes before switching to uv and having it finish in a few 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.

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/

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.

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.

uv is great and we’re switching over from conda for some projects. The resolver is lightning fast and the toml support is good.

Having said that, there are 2 areas where we still need conda:

- uv doesn’t handle non-python wheels, so if you need to use something like mkl, no luck

- uv assumes that you want to use one env per project. However with complex projects you may need to use a different env with different branches of your code base. Conda makes this easy - just activate the conda env you want — all of your envs can be stored in some central location outside your projects — and run your code. Uv wants to use the project toml file and stores the packages in .venv by default (which you don’t want to commit but then need different versions of). Yes you can store your project venv elsewhere with an env var but that’s not a practical solution. There needs to be support for multiple .toml files where the location of the env can be specified inside the toml file (not in an env var).

You may want to checkout uv’s workspaces - they’re very handy for large mono repos.

Thanks. I looked at that but I believe it solves a different problem.

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.

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.

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.

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

standardizing pyproject.toml helped but it didn't go quite far enough.

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

"depending on the project"

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).

Mypy doesn't install anything by default, you're probably setting the `--install-types` flag somehow.

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

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.

Maybe, but even if that is the case it's sooooo much better that even the worst case (fork when they try to monetise it) is way better than any alternatives.

> fork when they try to monetise it

To maintain a successful fork, not only are you going to need to find people who volunteer for maintaining a fork at that scale (including a large user base due to popularity), you’ll need to find skilled Rust developers, too.

That’s going to be immensely difficult.

I mean, maybe. But I'd still much rather take that risk than flagellate myself with Pip or Pyenv or Poetry.

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.

I think you mean packages, not modules. And actually there is site-packages, where your stuff lands when installed with pip, so there kind of is an official way. Just many tools implementing it.

It's open source. If necessary, uv can be forked and maintained entirely as OSS.

I am sold. Sign me up.

I have never used virtual environments well -- the learning curve after dealing with python installation and conda/pip setup and environment variables was exhausting enough. Gave up multiple times or only used them when working through step wise workshops.

If anyone can recommend a good learning resource - would love to take a stab again.

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.

> If the PSF were able to focus on tooling rather than their current focus

Well yeah maybe if the PSF were able to get their shit together it wouldn't have taken a single third party vendor to do it for them. But they weren't and it did, so here we are.

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...

Well maybe "fixes" is the wrong word. It certainly fixes the bad UX caused by virtual environments.

Basically it handles the virtual environments for you so you don't have to deal with their nonsense.

But you're right it doesn't fix it in the same way that Deno did.

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

Yeah, using the package manager is the logical choice and usually the most likely one to work.

IIRC, uv downloads dynamically linked builds of Python, which may or may not work depending on your distribution and whether linked libraries are locally available or not. Not sure if things have changed in recent times.

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.

It doesn't do anything differently beside the speed... Why do people keep praising it so much? It doesn't solve any of the real problems... come on. The problems weren't the tools, the problems are the bad design of the imports and packaging systems which cannot be addressed by an external tool: the language needs to change.

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

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.

I don’t know of a convenient way of doing it, but a clumsy way of doing it is to run this in your script:

  import os
  
  print(os.environ['VIRTUAL_ENV'] + '/bin/python')

Then, e.g. in VS Code, you bring up the command palette, run Python: Select Interpreter, and enter the result.

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

Discussed here:

> Using uv as your shebang line

— https://news.ycombinator.com/item?id=42855258

Since `env` doesn’t pass multiple arguments by default, the suggested line uses `-S`:

   #!/usr/bin/env -S 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

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 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?

If you need to package for Anaconda, uv has nothing to offer you. It's a replacement for a number of PyPA tools, so it's not compatible with Anaconda tools.

The selling point of uv is that it does things faster than the tools it aims to replace, but on a conceptual level it doesn't add anything substantially new. The tools it aims to replace were borne of the defects in Python import and packaging systems (something that Anaconda also tried to address, but failed). They are not good tools designed to do things the right way. They are band-aids designed to mitigate some of the more common problems stemming from the bad design choices in the imports and packaging systems.

My personal problem with tools like uv is that, just like Web browsers in the early days of the Web tried to win users by tolerating the mistakes made by the Web site authors, it allows to delay the solution of the essential problems that exist in Python infrastructure by offering some pain relief to those who are using the band-aid tools.

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 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/

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.

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.

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
  # ...

Yes but I then still then have to declare all dependencies for all tiny throwaway script, right now I have global python in pyenv and installed tons of plugins and didn't have too much issues with conflicts so was good enough for me

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

You could make an alias for creating a new python script that adds your favorite libraries as dependencies:

  alias newpy='function _newpy() { 
      default_deps=("rich" "requests");
      uv init --script "$1" && uv add "${default_deps[@]}" --script "$1"; 
  }; _newpy'

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 guess this is a joke but honestly I think that Python -> Rust is a pretty strong one.

I'd bet that the sort of person who is maintaining packaging for a bunch of Python users would like an opportunity to learn Rust on the job. I would.

IMO this is unlikely. Rust and Python have very little in common.

I can't say enough good things about UV. It has simplified and accelerated my python and Jupyter projects. I even run it in my pipelines.

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.

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.

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.

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.

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 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.

Astral ships a Docker image that provides their tox-uv. I saw maybe a 3x speed up setting up environments.

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 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...

We had to drop hatch for now, because it does not work well with uv's lockfiles. Someone opened an issue here: https://github.com/pypa/hatch/issues/1886. We use bare uv for now.

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.

> 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`.)

My biggest issue is using uv envs in vscode under WSL. Starting up interactive sessions takes forever. Its just too slow, can't figure out what the deal is.

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.

Yes because the pypi cupy/cudann packages now work seamlessly with jax. Until not long ago we had to use the conda packages.

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!

That's fair. I guess when you see people champion poetry (less so lately) you hope it works as well as pip/conda despite the complexities of pytorch in particular. Finding that the community in particular simply doesn't use that library has a shock of sorts - like this package manager is great, but "your type ain't welcome".

In any case I believe uv is trying to be _the_ solution and Id be pretty surprised if your libs weren't well supported, or on the roadmap at least.

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.

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 if you want a particular version of python to be installed

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

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

- uv run 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