Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switching from Pyenv to Uv

bluesock.org

Post reply on HN
Print view View original

51–60 of 239 posts

Re: Switching from Pyenv to Uv

#51

Post by BiteCode_dev »

new_user_final wrote: post #43
BiteCode_dev wrote: post #5

Earlier quoted context omitted.

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 i…

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.

Re: Switching from Pyenv to Uv

#52

Post by [deleted] »

OutOfHere wrote: post #32

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.

[deleted]

Re: Switching from Pyenv to Uv

#53

Post by kstrauser »

leejoramo wrote: post #46
kstrauser wrote: post #34

Earlier quoted context omitted.

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.

Re: Switching from Pyenv to Uv

#54

Post by claytonjy »

oblio wrote: post #31

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

Re: Switching from Pyenv to Uv

#56

Post by __mharrison__ »

xucian wrote: post #2

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

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"

Re: Switching from Pyenv to Uv

#58

Post by __mharrison__ »

turtlebits wrote: post #37
alexjplant wrote: post #26

Earlier quoted context omitted.

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 mis…

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.

Odd that it slowed down. I wondered what happened. For me and my clients, uv has been 2-4 orders of magnitude faster.

Re: Switching from Pyenv to Uv

#60

Post by lmeyerov »

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.

Post reply on HN