[HN Gopher] Switching from Pyenv to Uv
___________________________________________________________________
Switching from Pyenv to Uv
Author : harryvederci
Score : 69 points
Date : 2025-03-09 09:23 UTC (3 days ago)
(HTM) web link (bluesock.org)
(TXT) w3m dump (bluesock.org)
| xucian wrote:
| 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
| emgeee wrote:
| I've used uv to work on the feast feature store project to
| great success
| NeutralForest wrote:
| 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.
| ath3nd wrote:
| 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.
| rat87 wrote:
| 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
| theogravity wrote:
| 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?
| BiteCode_dev wrote:
| 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.
| NeutralForest wrote:
| 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.
| BiteCode_dev wrote:
| 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.
| new_user_final wrote:
| uv sync if you clone a github repo
| unsnap_biceps wrote:
| Uv in script mode has made me love python again.
| bnycum wrote:
| 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.
| rsyring wrote:
| 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
| NeutralForest wrote:
| I used to install Python through mise but now I just use uv
| tbh.
| rsyring wrote:
| Similar. But we get other benefits through mise, like tasks
| and other tool installs (e.g. Terraform). So we still use
| them together.
| NeutralForest wrote:
| That's fair, it's also nice if you have a backend in Python
| and a frontend in JS since mise also handles node.
| rsyring wrote:
| 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.
| NeutralForest wrote:
| 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 =)
| jdxcode wrote:
| 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
| rsyring wrote:
| 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.
| jdxcode wrote:
| 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
| rullopat wrote:
| Why in the Python ecosystem you change package manager every 2
| week?!? What's wrong with you pythonist people?!?
| fwip wrote:
| I think you might have your dates confused. Pyenv was first
| released about 8 years ago.
| alexjplant wrote:
| You're being downvoted (for snark presumably) but you have a
| point.
|
| During my tenures as a Python developer I've had to deal with
| pip, pipx, venv, pipenv, setuptools, conda, and poetry. I'd not
| heard of pyenv _or_ uv until this thread (or maybe I 've
| touched pyenv and got it confused with one of the 7 other tools
| I mentioned) and I'm sure there are other
| dependency/environment management tools floating around that I
| missed.
|
| Now that I'm back to Go it's `go get` with some mise tasks.
| It's a serious breath of fresh air. The Python ecosystem
| probably won't ever catch up to npm when it comes to cranking
| out shiny new things but it's definitely more bleeding edge
| than a lot of other languages.
| turtlebits wrote:
| In the past 10 years, virtualenv and pip have been perfectly
| fine for me. They still are. I ignored any new tooling.
|
| uv is great so far, I did run into a hiccup where moving from
| pip with a requirements.txt file to uv slowed a CI pipeline
| way down that I had to revert.
| quickslowdown wrote:
| 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!
| midhun1234 wrote:
| 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.
| baby_souffle wrote:
| 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/
| scribu wrote:
| The install speed alone makes it worthwhile for me. It went
| from minutes to seconds.
| BoorishBears wrote:
| 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.
| eikenberry wrote:
| 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.
| 0cf8612b2e1e wrote:
| 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?
| vslira wrote:
| 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"
| kubav027 wrote:
| 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.
| BiteCode_dev wrote:
| 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.
| moltar wrote:
| 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.
| kstrauser wrote:
| 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.
| moltar wrote:
| Thank you!! Will try it tomorrow.
| kstrauser wrote:
| You bet. I was _so_ happy to find that!
| leejoramo wrote:
| 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
| IshKebab wrote:
| 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.
| javchz wrote:
| 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.
| oblio wrote:
| How does this compare to Mise:
| https://mise.jdx.dev/lang/python.html ?
| OutOfHere wrote:
| 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.
| ashvardanian wrote:
| 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.
| tomrod wrote:
| 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.
| mrbonner wrote:
| 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.
___________________________________________________________________
(page generated 2025-03-12 23:00 UTC)