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

351–360 of 401 posts

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

#351

Post by deanishe »

EdwardDiego wrote: post #230
athrun wrote: post #106

Earlier quoted context omitted.

Pinning deps is a good thing, but it won't necessarily solve the issue of transitive dependencies (ie: the dependencies of requests itself for example), which will not be pinned themselves, given you don't have a lock file. To be clear, a lock file is strictly the better option—but for single file scripts it's a bit overkill.

1 file, 2 files, N files, why does it matter how many files? Use a lock file if you want transitive dependencies pinned. I can't think of any other language where "I want my script to use dependencies from the Internet, pinned to precise versions" is a thing.

> why does it matter how many files?

Because this is for scripts in ~/bin, not projects.

They need to be self-contained.

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

#352

Post by ofek »

remram wrote: post #343

The problem I have with uv is that it is not opinionated enough, or complete enough. It still needs a backend for building the package, and you still have a choice of backends. In other words, it is a nice frontend to hide the mess that is the Python packaging ecosystem, but the mess of an ecosystem is still there, and you still have to deal with it. You'll still have to go through hatchling's docs to figure out how…

Hatchling maintainer here :)

What limitations have you personally experienced?

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

#353

Post by tmvphil »

remram wrote: post #343

The problem I have with uv is that it is not opinionated enough, or complete enough. It still needs a backend for building the package, and you still have a choice of backends. In other words, it is a nice frontend to hide the mess that is the Python packaging ecosystem, but the mess of an ecosystem is still there, and you still have to deal with it. You'll still have to go through hatchling's docs to figure out how…

They are currently in the process of creating their own build system: https://github.com/astral-sh/uv/issues/3957#issuecomment-265...

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

#354

Post by zellyn »

I've been using Hermit to install uv, then pointing scripts at $REPO_ROOT/bin/uv. That gives you a repo where the scripts can be run directly after cloning (Hermit is smart enough to install itself if necessary).

Unfortunately, Hermit doesn't do Windows, although I'm pretty sure that's because the devs don't have Windows machines: PRs welcome.

https://github.com/cashapp/hermit

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

#355

Post by epistasis »

BossingAround wrote: post #196
barosl wrote: post #43

A very well written article! I admire the analysis done by the author regarding the difficulties of Python packaging. With the advent of uv, I'm finally feeling like Python packaging is solved. As mentioned in the article, being able to have inline dependencies in a single-file Python script and running it naturally is just beautiful. #!/usr/bin/env -S uv run # /// script # dependencies = ['requests', 'beautifulsoup4…

This looks horrible for anything but personal scripts/projects. For anything close to production purposes, this seems like a nightmare.

There's about 50 different versions of "production" for Python, and if this particular tool doesn't appear useful to it, you're probably using Python in a very very different way than those of us who find it useful. One of the great things about Python is that it can be used in such diverse ways by people with very very very different needs and use cases.

What does "production" look like in your environment, and why would this be terrible for it?

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

#356

Post by epistasis »

droelf wrote: post #164
epistasis wrote: post #138

Earlier quoted context omitted.

These are good points. But I think there needs to be an explanation why conda hasn't taken off more. Especially since it can handle other languages too. I've tried to get conda to work for me for more than a decade, at least once a year. What happens to me: 1) I can't solve for the tools I need and I don't know what to do. I try another tool, it works, I can move forward and don't go back to conda 2) it takes 20-60 m…

We've been working on all the shortcomings in `pixi`: pixi.sh It's very fast, comes with lockfiles and a project-based approach. Also comes with a `global` mode where you can install tools into sandboxed environments.

My completely unvarnished thoughts, in the hope that they are useful: I had one JIRA-ticket-worth of stuff to do on a conda environment, and was going to try to use pixi, but IIRC I got confused about how to use the environment.yml and went back to conda grudgingly. I still have pixi installed on my machine, and when I look through the list of subcommands, it does seem to probably have a better UX than conda.

When I go to https://prefix.dev, the "Get Started Quickly" section has what looks like a terminal window, but the text inside is inscrutable. What do they various lines mean? There's directories, maybe commands, check boxes... I don't get it. It doesn't look like a shell despite the Terminal wrapping box.

Below that I see that there's a pixi.toml, but I don't really want a new toml or yml file, there's enough repository lice to confuse new people on projects already.

Any time spent educating on packaging is time not spent on discovery, and is an impediment to onboarding.

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

#357

Post by procaryote »

datadeft wrote: post #291
procaryote wrote: post #204

Earlier quoted context omitted.

It's a lot harder to write rust than python.

If you check the TCO than probably it pays off. I am not sure about how much harder it is. I do not use lifetimes and I clone a lot. Still the performance and the reliability a Rust project has vs. Python is insane.

I think it depends a lot on what the task is.

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

#358

Post by vaylian »

mherrmann wrote: post #337
vaylian wrote: post #329

Earlier quoted context omitted.

Arnim Ronacher, author of rye (later uv) has very clearly highlighted that exact xkcd when he started working on rye. But he still decided that it was worth a try and as it turns out, rye/uv has become something that has a realistic chance of becoming the way to use python for most use-cases.

Cool point, thank you. I think his name is Armin.

Thanks. You are right. Unfortunately I can't edit my post any longer.

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

#359

Post by philsnow »

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…

In my mind, conda has always been a purpose-specific environment manager for people who live in data science / matplotlib / numpy / jupyter all day every day.

Ruby-the-language is now inseparable from Rails because the venn diagram of the “Ruby” community and the “rails” community is nearly a circle. It can be hard to find help with plain Ruby because 99% of people will assume you have the rails stdlib monkeypatches.

In a similar way, conda and data science seem to be conjoined, and I don’t really see anybody using conda as a general-purpose Python environment manager.

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

#360

Post by mathisd »

I really like uv and I have successfully got rid of miniconda but : - I wish there was a global virtual environment which could be referenced and activated from terminal. Not every new scripts needs their own .venv in their respective folder. uv takes the route of being project centered and based on file system, this works for me most of the time but sometime it doesn't. - I wish we could avoid the .python_version file and bundle it in the pyproject.toml file.
Post reply on HN