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

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

emily.space

Post reply on HN
Print view View original

371–380 of 1001 posts

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

#371

Post by no_wizard »

icedchai wrote: post #180
hardwaregeek wrote: post #149

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

poetry gave us lock files and consistent installs for years. uv is much, much faster however.

There was pipenv before that too, which also had a lockfile.

Funny how these things get forgotten to history. There's lots of prior art when it comes to replacing pip.

edit: here's an HN thread about pipenv, where many say the same things about it as they are about UV and Poetry before https://news.ycombinator.com/item?id=16302570

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

#372

Post by tecoholic »

ghusto wrote: post #354
mk89 wrote: post #239

Earlier quoted context omitted.

I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.

I've never even understood the virtual env dogma. I can see how version conflicts _could_ happen, but they never have. Admittedly, I'm surprised I never have issues installing globally, especially since others keep telling me what a terrible idea it is and how they had nightmare-scenario-X happen to them.

How do you work with multiple projects with different versions of the same dependencies? If you are using the “system python” for everything?

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

#373

Post by zahlman »

rieogoigr wrote: post #275

Is there a way to install this that doesn't involve piping a random URL to my shell interpreter?

Uv is available as a wheel from PyPI, so you can in fact `pip install uv` into an appropriate environment. Since it provides a command-line binary, Pipx will also happily install it into an environment it manages for you. And so on and so forth. (You can even install uv with uv, if you want to, for whatever reason.)

The wheel basically contains a compiled ~53MB (huh, it's grown in recent versions) Rust executable and a few boilerplate files and folders to make that play nice with the Python packaging ecosystem. (It actually does create an importable `uv` module, but this basically just defines a function that tells you the path to the executable.)

If you want it in your system environment, you may be out of luck, but check your full set of options at https://docs.astral.sh/uv/getting-started/installation/ .

The install script does a ton of system introspection. It seems to be structured quite similarly to the Julia installer, actually.

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

#374

Post by zahlman »

asaddhamani wrote: post #37

I find the python tooling so confusing now. There’s pip, virtualenv, pipx, uv, probably half a dozen others I’m missing. I like node, npm isolates by default, npx is easy to understand, and the ecosystem is much less fragmented. I see a python app on GitHub and they’re all listing different package management tools. Reminds me of that competing standards xkcd.

> I see a python app on GitHub and they’re all listing different package management tools.

In general, you can use your preferred package management tool with their code. The developers are just showing you their own workflow, typically.

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

#375

Post by wongarsu »

ghusto wrote: post #359
tomaskafka wrote: post #342

Earlier quoted context omitted.

So many times I have come onto a library or tool that would fix my problem, and then realized “oh crap, it’s in Python, I don’t want to spend few hours building a brittle environment for it only for that env to break next time I need to use it” - and went to look for a worse solution in better language.

I really don't get this. I can count on no hands the number of times I've had problems simply going "pip install cool-thing-i-found". Sure, this is just my experience, but I use Python a lot and use a lot of tools written in Python.

If you can install it with `pip install program-name` it's usually packaged well enough to just work. But if it's a random github repository with a requirements.txt with no or very few version numbers chances are that just running `pip install -r requirements.txt` will lead you down an hour+ rabbit hole of downgrading both your venv's python version and various packages until you get a combination that is close enough to the author`s venv to actually work

Usually happens to me when I find code for some research paper. Even something that's just three months old can be a real pain to get running

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

#376

Post by no_wizard »

anp wrote: post #205
hardwaregeek wrote: post #149

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

Might be worth noting that npm didn’t have lock files for quite a long time, which is the era during which I formed my mental model of npm hell. The popularity of yarn (again importing bundled/cargo-isms) seems like maybe the main reason npm isn’t as bad as it used to be.

npm has evolved, slowly, but evolved, thanks to yarn and pnpm.

It even has some (I feel somewhat rudimentary) support for workspaces and isolated installs (what pnpm does)

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

#377

Post by 1718627440 »

zahlman wrote: post #251
oblio wrote: post #173

Earlier quoted context omitted.

There are basically 0 other programming languages that use the "directory/shell integration activated virtual environment", outside of Python. How does the rest of the world manage to survive without venvs? Config files in the directory. Shocking, really :-)))

> Config files in the directory. The problem is, that would require support from the Python runtime itself (so that `sys.path` can be properly configured at startup) and it would have to be done in a way that doesn't degrade the experience for people who aren't using a proper "project" setup. One of the big selling points of Python is that you can just create a .py file anywhere, willy-nilly, and execute the code wit…

There are path configuration files (*.pth) and you can configure sys.path in the script itself?

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

#378

Post by IgorPartola »

ghusto wrote: post #359
tomaskafka wrote: post #342

Earlier quoted context omitted.

So many times I have come onto a library or tool that would fix my problem, and then realized “oh crap, it’s in Python, I don’t want to spend few hours building a brittle environment for it only for that env to break next time I need to use it” - and went to look for a worse solution in better language.

I really don't get this. I can count on no hands the number of times I've had problems simply going "pip install cool-thing-i-found". Sure, this is just my experience, but I use Python a lot and use a lot of tools written in Python.

Seconded. Python, even with virtualenv stuff, has never been bad. There have been a few things that have been annoying especially when you need system libraries (e.g. libav for PyAV to work, etc.), but you have the same issue with every other ecosystem unless the packages come with all batteries included.

To be fair to the GP comment, this is how I feel about Ruby software. I am not nearly as practiced at installing and upgrading in that ecosystem so if there was a way to install tools in a way that lets me easily and completely blow them away, I would be happier to use them.

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

#379

Post by zahlman »

ModernMech wrote: post #266

Honestly though it's a pretty rough indictment of Python that the best thing to happen in a decade is that people started writing Python tools in Rust. Not even a little Rust, uv is 98% Rust. I mean, they just released 3.14 and that was supposed to be a pretty big deal.

No, the "best thing that happened" (in TFA's author's opinion) is that this specific tool exists, with its particular design. Rust is an implementation detail. Most of the benefit that Uv offers over pip, in my analysis, is not a result of being written in Rust.

3.14 is a big deal.

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

#380

Post by the__alchemist »

caconym_ wrote: post #227
hardwaregeek wrote: post #149

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.

Same! And Python was my first, and is currently my second-highest-skill language. If someone's software's installation involves Python, I move on without trying. It used to be that it would require a Python 2 interpreter.

Honorable mention: Compiling someone else's C code. Come on; C compiles to a binary; don't make the user compile.

Post reply on HN