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

131–140 of 239 posts

Re: Switching from Pyenv to Uv

#131

Post by BiteCode_dev »

theogravity wrote: post #72
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…

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

Tool ?

Maybe you mean uv tool install ?

In that case it's something you don't need right now, uv tool is useful, but it's a bonus. It's to install 3rd party utilities outside of the project.

There is no equivalent to script yets, althought they are adding it as we speak.

uv run exec any command in the context of the venv (which is like a node_modules), you don't need to declare them prior to calling them.

e.g: uv run python will start the python shell.

Re: Switching from Pyenv to Uv

#132

Post by BiteCode_dev »

theogravity wrote: post #70
BiteCode_dev wrote: post #51

Earlier quoted context omitted.

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.

Thanks for the info. I looked at the group documentation, but it's not clear to me why I would want to use it, or where I would use it: https://docs.astral.sh/uv/concepts/projects/layout/#default-... (I'm a JS dev who has to write a set of python packages in a monorepo.)

sync is something you would rarely use, it's most useful for scripting.

uv run is the bread and meat of uv, it will run any command you need in the project, and ensure it will work by synching all deps and making sure your command can import stuff and call python.

In fact, if you run a python script, you should do uv run python the_script.py,

It's so common uv run the_script.py will work as a shortcut.

I will write a series of article on uv on bitecode.dev.

I will write it so that it work for non python devs as well.

Re: Switching from Pyenv to Uv

#133

Post by surfingdino »

zahlman wrote: post #90
surfingdino wrote: post #64

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

Could you give some detail on things you've found that still don't work as described?

I could use more guidance on migration for setups where development and testing is using Docker. I figured things out eventually. The issue here is lack of good tutorials that cover cases other than a happy path.

Re: Switching from Pyenv to Uv

#134

Post by maxrimue »

77ko wrote: post #86

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

Are you looking for something like `uv sync --upgrade`? This one should be re-assessing your dependencies (excluding version pinned ones of course) and regenerate the lockfile if I remember correctly.

https://docs.astral.sh/uv/reference/cli/#uv-sync--upgrade

Re: Switching from Pyenv to Uv

#135

Post by scratchyone »

vslira wrote: post #23

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

Re: Switching from Pyenv to Uv

#136

Post by globular-toast »

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

Re: Switching from Pyenv to Uv

#137

Post by Aeolun »

javchz wrote: post #40
IshKebab wrote: post #29

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'v…

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.

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

Re: Switching from Pyenv to Uv

#138

Post by ibic »

quickslowdown wrote: post #15

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…

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.

Re: Switching from Pyenv to Uv

#139

Post by jillesvangurp »

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.

Re: Switching from Pyenv to Uv

#140

Post by ibic »

fluidcruft wrote: post #80
quickslowdown wrote: post #15

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…

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

I'm not sure if I got your issue, but I can do platform-dependent `index` `pytorch` installation using the following snippet in `pyproject.toml` and `uv sync` just handles it accordingly.

[tool.uv.sources] torch = [{ index = "pytorch-cu124", marker = "sys_platform == 'win32'" }]

Post reply on HN