uv 0.3.0 released

I came across an enlightening phrase this week - “your community standards are set by the biggest asshole you won't ban” - in the replies to https://social.treehouse.systems/@marcan/112976577519704731, which perhaps not coincidentally is a thread making fun of a crowd of people with the same smell and lack of self-awareness as the OP.

Reading that line really drove home the realisation that my personal standards and principles have grown incompatible with a lot of situations I used to silently put up with ten or twenty years ago, and I am not going to compromise them for the sake of mere content consumption.

I cannot envision a future where I have anything constructive to add here given the state of things, so I intend to make this message my last and take these vague feelings of disappointment and regret with me. The thing is, I'm not the first one to give up. There used to be a lot more impromptu displays of domain expertise, and a lot less drive-by screeching about an article's use of pronouns and dogwhistle words used exclusively by racists and ignorant programming language elitism from Non-Practicing Entities and other utterly brain-dead drool from factory-produced plastic zombies with a pullstring on their back and the same five tiresome catchphrases. "Rust agenda" my ass, grow up.

Honestly I wish I could nuke all trace of my ever having been associated with this site. It wasn't a nazi bar when I subscribed 12 years ago, something changed there and there's no will to change it back.

good luck with whatever this is

There is a considerable difference between a "community bias" and a handful of folks drowning everything else through sheer volume.

The LWN FAQ (in the sidebar) has said this for at least 22 years:

> What does LWN stand for, anyway?
>
> LWN, initially, was "Linux Weekly News." That name has been deemphasized over time as we have moved beyond just the weekly coverage, and as we have looked at the free software community as a whole. We have yet to come up with a better meaning for LWN, however.

That said, it's possible that uv will never become something suitable for the kind of use case you're referring to - the challenge of supporting such a broad and often highly customised ecosystem may just be greater than it's worth. Which is fine - a really good solution that works for the low hanging 80% of use cases is still a really good solution, even if it's not usable everywhere.

My hope, though, is that the development of a tool that /can/ be a really good solution for the low hanging fruit may drive work in the broader ecosystem to allow the more heavily customised use cases to fit into that tool's paradigm (as well as encouraging the tool developers to meet in the middle). So far my experience with both ruff and uv is that they're /so/ much better than the alternatives (for the stuff they actually /do/ handle, which tends to grow very quickly) that there's a lot of impetus to adjust standard/common practises to support them - the 80% solution that's 10+ times faster than alternatives will start looking pretty damn attractive to the people in that 20%, even if they have to change the way they do things a bit . . .

> > from from https://gregoryszorc.com/docs/python-build-standalone/mai... makes me raise an eyebrow.

> It does raise eyebrows, but if the goal is to have something that can be redistributed as part of a packaged application (potentially even a single-file executable) I could see there being some value in avoiding including a GPLed shared library that might complicate licensing questions . . .

As is usually the case, this is the FSF being political. As they themselves point out, for practical purposes libraries should be licenced *L*GPL. So they consciously and deliberately licenced readline as *GPL*. Their code, their decision. But the response - which should have been forseen and expected (maybe it was) - was the immediate appearance of LGPL/BSD clones. It's this *politicking* which is pushing more and more people to permissive rather than copyleft licencing.

(No comments on whether such as move is sensible or not - from my POV it's all meaningless, anyway. The GPL argument just doesn't add up in a world of scripts and runtime linking ...)

Cheers,
Wol

Which is back to me moaning about SQL again - MV will run an entire query faster than SQL can run the AST optimiser! Because it pushes a lot of the optimisation work onto the database analyst, which then means the query itself has much less work to do.

In other words, Einstein's "Make everything as simple as possible, but no simpler". By making one part of the equation too simple ("premature optimisation"), you create excessive complexity elsewhere to compensate.

Cheers,
Wol

Heh. I guess they failed, because "How is this related to libuv?" was the first question I asked myself upon seeing this news article.

I'd even got as far as "well, Ultraviolet light is of high frequency, and that kind of means fast if you squint so Ultraviolet light could be an allusion to being fast and lightweight if you squint".

I do think this is improving, if somewhat slowly - uv is explicitly using pep 508 format dependencies and the project.dependencies/project.optional-dependencies tables as specified in pep 621, which means it's basically compatible with anything else that supports those standards. It can generate a frozen requirements.txt file with pep 508 compatible dependency specifications, which again should work with anything that supports that format. Where it's not striving for compatibility is the lock file, where there /is/ no standard - poetry has its own format, and uv uses a format that's clearly inspired by that but not identical. That will probably come down to whoever can get a workable and sufficiently well specified format broadly adopted before moving to standardise it. It's also expanding the project concept with new features like workspaces, which as far as I know aren't really a thing with any other python packaging tool - well have to see how that progresses, and if/to what extent it becomes a "standard feature".

Pixi seems to be using uv to handle dependency resolution calculations, and there are at least a few higher level tools that are using uv as a replacement for pip - the speed improvements you can get from that clearly make it an attractive proposition, any additional features aside. That suggests there's a reasonable chance we'll see things start to consolidate around uv (and the standards it supports) for core functionality, both reducing the number of competing implementations /and/ reducing the mutual incompatibility.

Historically the Python community has been good at shooting itself in the foot when it comes to packaging matters, so there's still hope for further chaos. Astral (the uv/ruff devs) seem to be pushing hard to reduce the chances of that, though, mostly by dint of raw speed (both runtime speed /and/ development speed) - they're not only talking about "cargo for Python", they're actually /implementing/ it, /now/.