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

191–200 of 239 posts

Re: Switching from Pyenv to Uv

#191

Post by insane_dreamer »

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…

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

Re: Switching from Pyenv to Uv

#192

Post by baq »

xenophonf wrote: post #186
baq wrote: post #124

Earlier quoted context omitted.

It does everything with less surprises and faster. Just try it.

> Just try it. I don't need to be told to RTFM. I was asking for advice. My attention span is my most valuable commodity, and since I'm not really surprised or slowed down by setuptools, etc., it sounds like uv probably isn't worth investigating. Thanks.

It probably is. Just try it is the advice.

Re: Switching from Pyenv to Uv

#193

Post by dagw »

guappa wrote: post #172
BoorishBears wrote: post #44

Earlier quoted context omitted.

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.

Why would you be redoing your venv more than once?

Once rebuilding your venv takes negligible time, it opens up for all kinds of new ways to develop. For example I now always run my tests in a clean environment, just to make sure I haven't added anything that only happens to work in my dev venv.

Re: Switching from Pyenv to Uv

#194

Post by serjester »

insane_dreamer wrote: post #191
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…

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

You may want to checkout uv’s workspaces - they’re very handy for large mono repos.

Re: Switching from Pyenv to Uv

#195

Post by sorenjan »

pzo wrote: post #118
js2 wrote: post #108

Earlier quoted context omitted.

Yes, uv is well suited to that use case by declaring your Python version and/or dependencies right in the script itself: https://docs.astral.sh/uv/guides/scripts/#declaring-script-d... You can use an alternate shebang line so you can run the script directly: #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.12" # dependencies = [ # "requests", # "typer-slim", # ] # /// import requests import typ…

Yes but I then still then have to declare all dependencies for all tiny throwaway script, right now I have global python in pyenv and installed tons of plugins and didn't have too much issues with conflicts so was good enough for me

You could make an alias for creating a new python script that adds your favorite libraries as dependencies:

  alias newpy='function _newpy() { 
      default_deps=("rich" "requests");
      uv init --script "$1" && uv add "${default_deps[@]}" --script "$1"; 
  }; _newpy'

Re: Switching from Pyenv to Uv

#196

Post by quickslowdown »

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

You can control dependencies per platform

https://docs.astral.sh/uv/concepts/projects/dependencies/#pl...

Not sure if it's as granular as you might need

Re: Switching from Pyenv to Uv

#197

Post by Hackbraten »

IshKebab wrote: post #181
guappa wrote: post #142

Earlier quoted context omitted.

uv belongs to a startup. They will surely introduce some wacky monetisation scheme sooner or later. I wouldn't get too used to it.

Maybe, but even if that is the case it's sooooo much better that even the worst case (fork when they try to monetise it) is way better than any alternatives.

> fork when they try to monetise it

To maintain a successful fork, not only are you going to need to find people who volunteer for maintaining a fork at that scale (including a large user base due to popularity), you’ll need to find skilled Rust developers, too.

That’s going to be immensely difficult.

Re: Switching from Pyenv to Uv

#198

Post by OutOfHere »

__mharrison__ wrote: post #69
OutOfHere wrote: post #66

Earlier quoted context omitted.

In an ideal world they shouldn't have to, but in the real world, it makes it easier for enterprises to adopt without friction. Adopting three tools is a threefold bigger challenge in enterprises, but thinking about it as a single tool makes it more amenable to enterprise adoption where it's needed the most. The merging I suggest is only logical, more like a bundling.

Hmmm, I've never seen that and I feel like I work with some pretty locked down companies.

If you can get whatever you want into a production workflow, then it's not really that locked down, is it...

Re: Switching from Pyenv to Uv

#199

Post by kstrauser »

dagw wrote: post #193
guappa wrote: post #172

Earlier quoted context omitted.

Why would you be redoing your venv more than once?

Once rebuilding your venv takes negligible time, it opens up for all kinds of new ways to develop. For example I now always run my tests in a clean environment, just to make sure I haven't added anything that only happens to work in my dev venv.

That's smart. Oh, you used `pip install` to fix a missing import, but forgot to add it to pyproject.toml? You'll find out quickly.

Re: Switching from Pyenv to Uv

#200

Post by fluidcruft »

DrBenCarson wrote: post #107
fluidcruft wrote: post #80

Earlier quoted context omitted.

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

It sounds like you’re just looking for dependency groups? uv supports adding custom groups (and comes with syntactic sugar for a development group

It is... but basically it need to remember which groups are sync'd. For example if you use an extra, you have to keep track of it constantly because sync thrashes around between states all the time unless you play close and tedious attention. At least I haven't figured out how to make it remember which extras are "active".

    uv sync --extra gpu
    uv add matplotlib # the sync this runs undoes the --extra gpu
    uv sync # oops also undoes all the --extra
What you have to do to avoid this is to remember to use --no-sync all the time and then meticulously manually sync while remembering all the extras that I do actually currently want:

    uv sync --extra gpu --extra foo --extra bar
    uv add --no-sync matplotlib
    uv sync --extra gpu --extra foo --extra bar
It's just so... tedious and kludgy. It needs an "extras.lock" or "sync.lock" or something. I would love it if someone tells me I'm wrong and missing something obvious in the docs.
Post reply on HN