Switching from Pyenv to Uv • Hacker News Board

Re: Switching from Pyenv to Uv

#211

Post by tmaly » Thu, Mar 13, 2025, 7:35 PM UTC

shawnz wrote: post #114

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

Getting the right version of PyTorch installed to have the correct kind of acceleration on each different platform you support has been a long-standing headache across many Python dependency management tools, not just uv. For example, here's the bug in poetry regarding this issue: https://github.com/python-poetry/poetry/issues/6409 As I understand it, recent versions of PyTorch have made this process somewhat easier,…

I end up going to the torch website and they have a nice little UI I can click what I have and it gives me the pip line to use.

Re: Switching from Pyenv to Uv

#212

Post by BoorishBears » Thu, Mar 13, 2025, 8:00 PM UTC

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?

It has nothing to do with redoing venv: some package installs were just taking multiple minutes.

I cancelled one at 4 minutes before switching to uv and having it finish in a few seconds

Re: Switching from Pyenv to Uv

#213

Post by shawnz » Thu, Mar 13, 2025, 8:12 PM UTC

tmaly wrote: post #211

shawnz wrote: post #114

Earlier quoted context omitted.

Getting the right version of PyTorch installed to have the correct kind of acceleration on each different platform you support has been a long-standing headache across many Python dependency management tools, not just uv. For example, here's the bug in poetry regarding this issue: https://github.com/python-poetry/poetry/issues/6409 As I understand it, recent versions of PyTorch have made this process somewhat easier,…

I end up going to the torch website and they have a nice little UI I can click what I have and it gives me the pip line to use.

That's fine if you are just trying to get it running on your machine specifically, but the problems come in when you want to support multiple different combinations of OS and compute platform in your project.

Re: Switching from Pyenv to Uv

#214

Post by zelphirkalt » Thu, Mar 13, 2025, 8:15 PM UTC

guappa wrote: post #144

baq wrote: post #121

Earlier quoted context omitted.

The risk is obviously uv losing funding. I kinda hope the PSF has thought about this and has a contingency plan for uv winning and dying/becoming enshittified soon after.

If they never made any plan about how modules are installed and there is no official way… i doubt they made a plan about uv.

I think you mean packages, not modules. And actually there is site-packages, where your stuff lands when installed with pip, so there kind of is an official way. Just many tools implementing it.

Re: Switching from Pyenv to Uv

#215

Post by xenophonf » Thu, Mar 13, 2025, 9:10 PM UTC

baq wrote: post #192

xenophonf wrote: post #186

Earlier quoted context omitted.

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

That's unhelpful.

To answer my own question—and to actually help other people with similar use cases—I read about uv's build process and dependency locking. It does not appear to be able to lock dependencies for build distributions (wheels).

https://docs.astral.sh/uv/concepts/projects/build/

https://docs.astral.sh/uv/pip/compile/

However, it does mention that Python supports multiple build systems, which I didn't know, so this hasn't been a complete waste of my time.

Thanks!

Re: Switching from Pyenv to Uv

#216

Post by fluidcruft » Thu, Mar 13, 2025, 9:24 PM UTC

DrBenCarson wrote: post #203

fluidcruft wrote: post #200

Earlier quoted context omitted.

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 # oop…

To make the change in your environment: 1. Create or edit the UV configuration file in one of these locations: - `~/.config/uv/config.toml` (Linux/macOS) - `%APPDATA%\uv\config.toml` (Windows) 2. Add a section for default groups to sync: ```toml [sync] include-groups = ["dev", "test", "docs"] # Replace with your desired group names ``` Alternatively, you can do something similar in pyproject.toml if you want to apply…

Thank you! That's good to know. Unfortunately it doesn't seem to work for "extras". There may be some target other than sync.include-groups but I haven't found it yet.

What I am struggling with is what you get after following the Configuring Accelerators With Optional Dependencies example:

https://docs.astral.sh/uv/guides/integration/pytorch/#config...

Part of what that does is set up rules that prevent simultaneously installing cpu and gpu versions (which isn't possible). If you use the optional dependencies example pyproject.toml then this is what happens:

    $ uv sync --extra cpu --extra cu124
    Using CPython 3.12.7
    Creating virtual environment at: .venv
    Resolved 32 packages in 1.65s
    error: Extras `cpu` and `cu124` are incompatible with the declared conflicts: {`project[cpu]`, `project[cu124]`}

And if you remove the declared conflict, then uv ends up with two incompatible sources to install the same packages from

    uv sync --extra cpu --extra cu124
    error: Requirements contain conflicting indexes for package `torch` in all marker environments:
    - https://download.pytorch.org/whl/cpu
    - https://download.pytorch.org/whl/cu124

After your comment I initially thought that perhaps the extras might be rewritten as group dependencies somehow to use the ~/.config/uv/config.toml but according to the docs group dependencies are not allowed to have conflicts with each other and must be installable simultaneously (makes sense since there is an --all-groups flag). That is you must be able to install all group dependencies simultaneously.

Re: Switching from Pyenv to Uv

#217

Post by fluidcruft » Thu, Mar 13, 2025, 9:31 PM UTC

0xcoffee wrote: post #104

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

Does this help? https://github.com/astral-sh/uv/pull/7851

Unfortunately it didn't seem to help

https://news.ycombinator.com/threads?id=fluidcruft#43355636

Re: Switching from Pyenv to Uv

#218

Post by __mharrison__ » Thu, Mar 13, 2025, 9:44 PM UTC

OutOfHere wrote: post #198

__mharrison__ wrote: post #69

Earlier quoted context omitted.

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

If you can get uv in, ruff should be easy...

Re: Switching from Pyenv to Uv

#219

Post by fluidcruft » Thu, Mar 13, 2025, 9:53 PM UTC

shawnz wrote: post #114

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

Getting the right version of PyTorch installed to have the correct kind of acceleration on each different platform you support has been a long-standing headache across many Python dependency management tools, not just uv. For example, here's the bug in poetry regarding this issue: https://github.com/python-poetry/poetry/issues/6409 As I understand it, recent versions of PyTorch have made this process somewhat easier,…

uv actually handles thr issues described there very well (uv docs have have a page showing a few ways to do it). The issue for me is uv has massive amnesia about which one was selected and you end up trashing packages because of that. uv is very fast at thrashing though so it's not as bad as if poetry were thrashing.

Re: Switching from Pyenv to Uv

#220

Post by loeber » Thu, Mar 13, 2025, 11:07 PM UTC

baq wrote: post #121

loeber wrote: post #83

Earlier quoted context omitted.

Strong agree. The respectful act of other package managers would be consider themselves deprecated and point to uv instead.

The risk is obviously uv losing funding. I kinda hope the PSF has thought about this and has a contingency plan for uv winning and dying/becoming enshittified soon after.

It's open source. If necessary, uv can be forked and maintained entirely as OSS.