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

A year of uv: pros, cons, and should you migrate

bitecode.dev

Post reply on HN
Print view View original

121–130 of 401 posts

Re: A year of uv: pros, cons, and should you migrate

#121

Post by BrenBarn »

something98 wrote: post #37

Can someone explain a non-project based workflow/configuration for uv? I get creating a bespoke folder, repo, and uv venv for certain long-lived projects (like creating different apps?). But most of my work, since I adopted conda 7ish years ago, involves using the same ML environment across any number of folders or even throw-away notebooks on the desktop, for instance. I’ll create the environment and sometimes add n…

Yeah, this is how I feel too. A lot of the movement in Python packaging seems to be more in managing projects than managing packages or even environments. I tend to not want to think about a "project" until very late in the game, after I've already written a bunch of code. I don't want "make a project" to be something I'm required or even encouraged to do at the outset.

Re: A year of uv: pros, cons, and should you migrate

#122

Post by 8n4vidtmkvmk »

woodruffw wrote: post #104
8n4vidtmkvmk wrote: post #86

Earlier quoted context omitted.

You know what we need? In both python and JS, and every other scripting language, we should be able to import packages from a url, but with a sha384 integrity check like exists in HTML. Not sure why they didn't adopt this into JS or Deno. Otherwise installing random scripts is a security risk

Python has fully-hashed requirements[1], which is what you'd use to assert the integrity of your dependencies. These work with both `pip` and `uv`. You can't use them to directly import the package, but that's more because "packages" aren't really part of Python's import machinery at all. (Note that hashes themselves don't make "random scripts" not a security risk, since asserting the hash of malware doesn't make it…

Right, still a security risk, but at least if I come back to a project after a year or two I can know that even if some malicious group took over a project, they at least didn't backport a crypto-miner or worse into my script.

Re: A year of uv: pros, cons, and should you migrate

#124

Post by teej »

sieve wrote: post #12

Well, big fan of uv. But... the 86GB python dependency download cache on my primary SSD, most of which can be attributed to the 50 different versions of torch, is testament to the fact that even uv cannot salvage the mess that is pip. Never felt this much rage at the state of a language/build system in the 25 years that I have been programming. And I had to deal with Scala's SBT ("Simple Build Tool") in another life.

You can specify platform specific wheels in your pyproject.toml

    [[tool.uv.index]]
    name = "pytorch-cu124"
    url = "https://download.pytorch.org/whl/cu124"
    explicit = true
    [[tool.uv.index]]
    name = "pytorch-cpu"
    url = "https://download.pytorch.org/whl/cpu"
    explicit = true
    [tool.uv.sources]
    torch = [
    { index = "pytorch-cu124", marker = "platform_system != 'Darwin'" },
    { index = "pytorch-cpu", marker = "platform_system == 'Darwin'" },
    ]

Re: A year of uv: pros, cons, and should you migrate

#125

Post by __rito__ »

Is there a conda to uv migration tutorial written by anyone?

I have installed miniconda system-wide. For any Python package that I use a lot, I install them on base environment. And on other environments. Like ipython.

For every new project, I create a conda environment, and install everything in it. Upon finishing/writing my patch, I remove that environment and clean the caches. For my own projects, I create an environment.yaml and move on.

Everything works just fine. Now, the solving with mamba is fast. I can just hand someone the code and environment.yaml, and it runs on other platforms.

Can someone say why using uv is a good idea? Has anyone written a migration guide for such use cases?

I am mightily impressed by one line dependency declaration in a file. But I don't know (yet) where the caches are stored, how to get rid of them later, etc.

Re: A year of uv: pros, cons, and should you migrate

#126

Post by BrenBarn »

Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years.

> Being independent from Python bootstrapping

Yep, conda.

> Being capable of installing and running Python in one unified congruent way across all situations and platforms.

Yep, conda.

> Having a very strong dependency resolver.

Yep, conda (or mamba).

The main thing conda doesn't seem to have which uv has is all the "project management" stuff. Which is fine, it's clear people want that. But it's weird to me to see these articles that are so excited about being able to install Python easily when that's been doable with conda for ages. (And conda has additional features not present in uv or other tools.)

The pro and con of tools like uv is that they layer over the base-level tools like pip. The pro of that is that they interoperate well with pip. The con is that they inherit the limitations of that packaging model (notably the inability to distribute non-Python dependencies separately).

That's not to say uv is bad. It seems like a cool tool and I'm intrigued to see where it goes.

Re: A year of uv: pros, cons, and should you migrate

#127

Post by necessary »

BrenBarn wrote: post #126

Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing…

The killer feature of uv for me is much faster uv pip install -r requirements.txt.

Re: A year of uv: pros, cons, and should you migrate

#128

Post by upbeat_general »

I tried out uv a bit ago and dropped it. But about two weeks ago, I switched to it and migrated two projects with no issues.

Things like pypi sources per dep are there finally.

I still find rough points (as many others pointed out, especially with non sandboxed installs), that are problematic, but on the whole it’s better than Mamba for my use.

Re: A year of uv: pros, cons, and should you migrate

#130

Post by upbeat_general »

cjohnson318 wrote: post #9

Honest question: is uv more reproducible/portable than cramming your Python project into a Docker container? I've used pyenv, pip, venv, and a couple of other things, and they all work fine, at first, in simple scenarios.

It’s less reproducible than docker (assuming the pip usage is correct). Docker specifies a lot of OS properties that UV ignores.

That being said, UV is great.

Post reply on HN