Live data from Hacker News

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

951–960 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#951

Earlier quoted context omitted.

""" uv is straightforward to install. There are a few ways, but the easiest (in my opinion) is this one-liner command — for Linux and Mac, it’s: curl -LsSf https://astral.sh/uv/install.sh | sh """ Also isn't great. But that's how homebrew is installed, so ... shrug ... ? Not to bash uv/homebrew, they are better than most _easy_ alternatives.

There's a completely irrational knee-jerk reaction to curl|sh. Do you trust the source or not? People who gripe about this will think nothing of downloading a tarball and running "make install", or downloading an executable and installing it in /usr/local/bin. I will happily copy-paste this from any source I trust, for the same reason I'll happily install their software any other way.

It really depends on the use case. A one-off install on a laptop that I don't use for anything that gets close to production - fine by me.

For anything that I want to depend on, I prefer stronger auditability to ease of install. I get it, theoretically you can do the exact same thing with curl/sh as with git download/inspecting dependencies, installing the source and so on. But in reality, I'm lazy (and per another thread, a 70s hippie) and would like to nix any temptation to cut corners in the bud.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#952
post #670

The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see…

Interesting. I never start working on something without a rough idea of what I am working on, be that just researching something or a program; and uv makes it extremely easy to create a folder, and make it a project. Could it be that you’re just used to separate environments causing so much pain that you avoid it unless you’re serious about what you’re doing?

If they are like me, they are just exploring different data, ideas and stuff - maybe without knowing/having descided if it will be a project. Many times it nice to use Python as a tool explore some data.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#953

Earlier quoted context omitted.

I don't want type annotations. Was kinda the point of Python not to deal with types.

One problem is when people store different types in the same variable, what type is it at the time I use it. Types save you cognitive effort and catch errors earlier, while writing code, not later when running or testing

They shouldn't do that. I get how adding more checks obviously helps in a way, but only if you ignore the cost. It's not worth the effort that you could instead spend writing better tests. Most of the time your type is like FooFactory which doesn't tell you much anyway.

Then again it's not so bad if you're willing to make AI add all the types and not even care.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#954
post #485

Earlier quoted context omitted.

Have you figured out a good way to manage CUDA dependencies with uv?

CUDA is part of our cluster install scripts, we don't manage that with uv or conda. To me, that should be system software that only gets installed once.

What do you do when a new CUDA version is released?

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#955

Does uv handle CUDA versioning? This is the big reason I'm still on conda -- I can save a whole environment with `conda list --explicit`, including CUDA stuff, and I can set up a new machine with the same environment just from that file.

It handles CUDA version for PyTorch: https://docs.astral.sh/uv/guides/integration/pytorch/#instal...

Thanks for this - does this actually install CUDA, or just give a pytorch install for a particular CUDA version?

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#956

Earlier quoted context omitted.

It has always been like this. The only way to get glory and money in the Python space [1] is to set up a new package manager or package repository or both. Active State, Enthought, Anaconda, now Astral. [1] Discounting pure SaaS companies that just use Python but offer no tools.

Active state, that’s a name I’ve not heard in a long time. A long time.

So you know him then?

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#957

Earlier quoted context omitted.

You can't just create yourself an "everything" environment with UV and then experiment with it? Honest question. I think you're basically suggesting that you'd have a VM or something that has system-high packages already preinstalled and then use UV on top of it?

If so, it's certainly not obvious. I mean look at the docs: https://docs.astral.sh/uv/getting-started/features/ I don't see anything resembling "environments" in the list of features or in the table of contents. In some sections there is stuff like "When working on a project with uv, uv will create a virtual environment as needed", but it's all about environments as tied to particular projects (and maybe tools). You…

I assume if you stick a .venv in your home directory it'll essentially be available globally as you desired.. and overridden in project specific .venv or similar

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#958

Earlier quoted context omitted.

Perhaps the language design is more important than the tooling?

How do you think Python's language design is superior to Ruby's?

Readability > write ability

Rubies meta-prigramming often leads to too much magic, lack of understanding.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#959
I thoroughly enjoy uv, having used poetry and requirements.txt prior, but it does come with its faults in a large codebase. Admittedly, I don’t know whether they re due to uv’s infancy, or PEP restrictions.

For example:

    1. uv sync should update by default (like poetry)
    2. uv lock revision and dependency resolver keep changing and it makes it hard to figure out if changes to our uv.lock are real or due to separate versions of uv among developers
    3. uv pre-release dependency rules should be able to be disabled with either a sys_marker or specific case like pinning a version
 
Some other pain points but I can’t remember them all at the top of my head..
Post reply on HN