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.

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/

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.

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

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.

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.

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

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.

Adding dependencies to the script directly was a game-changer. I was able to write a script for a friend with no coding background at all and everything ran smoothly on his machine. No more rabbit holes of bundling Python packages and setting up environments!

Did you try pixi [1] too?

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

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

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.

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

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.

Every time people have debates over the merits of languages I always put developer environment at the top of my list. Build tools, IDE, readable stack traces. Those things boost productivity for more than concise list comprehensions or any gimmicky syntax thing. It's why Python always felt stone age to me despite have such lovely semantics.

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.

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

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.

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.

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?

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.

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

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

    #!/home/tetha/Tools/uv run

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

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.