Switching from Pyenv to Uv

I highly, highly recommend uv. It solves &amp; installs dependencies incredibly fast, and the CLI is very intuitive once you&#x27;ve memorized a couple commands. It handles monorepos well with the &quot;workspaces&quot; concept, it can replace pipx with &quot;uv tool install,&quot; handle building &amp; publishing, and the docker image is great, you just add a FROM line to the top and copy the bin from &#x2F;uv.<p>I&#x27;ve used &#x27;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&#x27;t have to reach for other tools, or really even think about what uv is doing. It just works, and it works great.<p>I even use it for small scripts. You can run &quot;uv init --script &lt;script_name.py&gt;&quot; and then &quot;uv add package1 package2 package3 --script &lt;script_name.py&gt;&quot;. 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 &quot;uv run &lt;script_name.py&gt;,&quot; uv installs everything you need and executes the script. Subsequent executions use the cached dependencies so it starts immediately.<p>If you&#x27;re going to ask me to pitch you on why it&#x27;s better than your current preference, I&#x27;m not going to do that. Uv is very easy to install &amp; test, I really recommend giving it a try on your next script or pet project!

Uv really fixes Python. It takes it from &quot;oh god I have to fight Python again&quot; to &quot;wow it was actually fast and easy&quot;.<p>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&#x27;m serious. (It&#x27;s not going to happen though because the Python community has no taste.)<p>The only very minor issue I&#x27;ve had is once or twice the package cache invalidation hasn&#x27;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.

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.<p>I have already setup CI&#x2F;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&#x2F;CD. I do not think it is worth the time right now.<p>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.<p>Another thing to consider in long term is how astral tooling would change when they will need to make money.

UV is such a big improvement that it moves Python from my &quot;would use again if I had to, but would really not look forward to it&quot; pile to my &quot;happy to use this as needed&quot; 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.<p>E.g.:<p><pre><code> #!&#x2F;usr&#x2F;bin&#x2F;env python3 # &#x2F;&#x2F;&#x2F; script # requires-python = &quot;&gt;=3.11&quot; # dependencies = [ # &quot;psycopg2-binary&quot;, # &quot;pyyaml&quot;, # ] # &#x2F;&#x2F;&#x2F; </code></pre> Then -<p><pre><code> uv run -s file.py</code></pre>

For my use cases, uv is so frictionless it has effectively made Python tolerable for me. I primarily discovered it via Simon Willison&#x27;s (@simonw) blog posts[1]. I recommend his blog highly.<p>1. <a href="https:&#x2F;&#x2F;simonwillison.net&#x2F;tags&#x2F;uv&#x2F;" rel="nofollow">https:&#x2F;&#x2F;simonwillison.net&#x2F;tags&#x2F;uv&#x2F;</a>

I&#x27;m using exclusively uv for personal projects - and small prototypes at work - and I can&#x27;t recommend it enough.<p>Uv makes python go from &quot;batteries included&quot; to &quot;attached to a nuclear reactor&quot;

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

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.

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.<p>It replaces a whole stack, and does each feature better, faster, with fewer modes of failure.

15 year Python dev who usually adopts tooling slowly. Just do it, uv&#x27;s absolutely worth it.<p>I also use mise with it, which is a great combination and gives you automatic venv activation among other things.<p>See, among other mise docs related to Python, <a href="https:&#x2F;&#x2F;mise.jdx.dev&#x2F;mise-cookbook&#x2F;python.html" rel="nofollow">https:&#x2F;&#x2F;mise.jdx.dev&#x2F;mise-cookbook&#x2F;python.html</a><p>See also a Python project template I maintain built on mise + uv: <a href="https:&#x2F;&#x2F;github.com&#x2F;level12&#x2F;coppy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;level12&#x2F;coppy</a>

I dabble with python occasionally and I&#x27;m always fighting with tools and tool combinations that don&#x27;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&#x27;t resolve libraries I installed). I got it working eventually but it wasn&#x27;t a great experience.<p>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.<p>Will give this a try next time I need to do some python stuff.

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.

I want to switch to uv from pyenv but one use case that didn&#x27;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.

How does this compare to Mise: <a href="https:&#x2F;&#x2F;mise.jdx.dev&#x2F;lang&#x2F;python.html" rel="nofollow">https:&#x2F;&#x2F;mise.jdx.dev&#x2F;lang&#x2F;python.html</a> ?

What does uv offer over bog-standard setuptools, pip, pip-tools, and build?<p>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.

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

I decided to give uv a shot on my new machine over pyenv and I&#x27;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?<p>I&#x27;m very comfortable with pyenv, but am extremely open to new stuff

I converted along with most of the people in this thread.<p>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 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).<p>I&#x27;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&#x2F;pip-tools and plain venv&#x27;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&#x27;ve been able to reduce it to basically one Make target calling uv to do it all.

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.<p>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 &amp; adoption for native and hardware-accelerated tools.

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

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

&gt; Maybe I installed some other things for some reason lost in the sands of time.<p>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&#x27;t get a wheel was `python-hglib`, which turned out to be pure Python with a relatively straightforward `setup.py`.)

I switched to hatch last year for many projects, its been quite pleasant.<p>Has anyone used both hatch and uv, and could comment on that comparison?<p>EDIT: quick google gives me these opinions[1]<p>[1]: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Python&#x2F;comments&#x2F;1gaz3tm&#x2F;hatch_or_uv_for_a_new_project&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Python&#x2F;comments&#x2F;1gaz3tm&#x2F;hatch_or_uv...</a>

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

Are people seeing it work well in GPU&#x2F;pydata land and creating multiplatform docker images?<p>In the data science world, conda&#x2F;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.

Is there a guide for how to use uv if you&#x27;re a JS dev coming from pnpm?<p>I just want to create a monorepo with python that&#x27;s purely for making libraries (no server &#x2F; apps).<p>And is it normal to have a venv for each library package you&#x27;re building in a uv monorepo?

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

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.

uv is excellent! The only think I&#x27;m missing is an easy way to update all packages in an env, something like `uv update --all` or `uv update plotly`.<p>Which would fit in with existing uv commands[1] like `uv add plotly`.<p>There is an exisiting `uv lock --upgrade-package requests` but this feels a bit verbose.<p>[1]: <a href="https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;guides&#x2F;projects&#x2F;#creating-a-new-project" rel="nofollow">https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;guides&#x2F;projects&#x2F;#creating-a-new-pr...</a>

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

This makes sense for people keen on pyenv.<p>I&#x27;m still very keen on virtualenvwrapper, I hope that the fast dependency resolution and install of uv can come there and to poetry.

I can&#x27;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 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.

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

Here we go again.