pdonis

This comes as a complete surprise to me. I thought the whole point of specifying the build backend in pyproject.toml was so the project owner can choose which build backend their project gets built with, and have that choice automatically enforced by tools.

Are you saying this kind of thing is allowed by the Python spec? If so, where? Can you give a specific document?

> The author even highlights

What he means is that the project owner doesn't have to, for example, use uv-build as their build backend in pyproject.toml just because they are using uv as their overall project management tool. I do not think he means that he, as a distro packager, is free to just ignore what's in pyproject.toml.

That is so utterly different from what we humans are used to that we can't even comprehend it, and we anthropomorphize LLMs because we can't make any sense of them otherwise. We can't comprehend that these things that emit text that looks like human text don't have all of the other things that lie underneath our words when we humans talk.

Nothing in the Python spec guarantees that the resulting build artifact will be identical if the build system dependencies update but nothing else in the project does. So what's a "build everything from source" distro to do? If it's possible that updating the build dependency will change the build artifact, doesn't it have to rebuild?

Which defeats the purpose of doing the build in a virtualenv, which is to avoid any possible collision with or contamination by other stuff that's installed on the system by using a fresh copy of everything.

From what I can gather, Gentoo's Python build system does use a virtualenv [1]. Maybe that's not your definition of "distro land", but it appears to be Gentoo's.

It's not clear to me exactly what frontend build tool is used, whether it's one of the well known ones or something that the Gentoo developers coded themselves. However, if it's using a virtualenv, it's going to have to re-fetch the build backend and rebuild it.

[1] https://projects.gentoo.org/python/guide/basic.html

I would say it's doing what it believes is necessary for the Python ecosystem. The build backend is an explicit part of the specification of a Python project.

> Does Gentoo also recompile every C/C++ library in the dependency tree every time GCC pushes a minor version bump?

No, because C/C++ libraries don't have an explicit specification of the build tool to be used in their project, the way a Python project does.

That's my understanding, yes.

If a compatible version is already present, yes, a frontend can just use it if it's within the semver range specified.

But in many cases, builds are done in a fresh virtual environment that has nothing installed. In such a case, the only option is to download the latest version that's in the semver range specified. That's how the "build" frontend works, for example, unless you specify a flag to keep it from creating a fresh virtual environment.

But a new patch release will be within the same semver bound, so it amounts to the same thing.

> If you leave the build backend version unconstrained, the build frontend is allowed to resolve any version it sees fit, including the version it already has.

What do build frontends actually do, though?

If every new patch version is still within the semver range specified in a project that uses uv-build, then yes, every Gentoo user will have to rebuild that new patch version of uv-build in order to rebuild that project. And since the build backend is a dependency of the project, pushing a new patch version will trigger a rebuild of the project.

So every Gentoo user that has a Python project that uses uv-build ends up having to rebuild uv-build, and then every Python project they have that uses it, every time uv-build pushes an update.

Other distros don't necessarily have quite the same problem because, if they include packages of Python projects, they don't normally track the build backend as a dependency. So if uv-build pushes an update, the distro would push an updated package for uv-build, but they wouldn't look at every Python project they package to see if it used uv-build as a build backend and rebuild it if it did. It's the "rebuild from source every time" aspect of Gentoo that forces that connection.

This doesn't make sense. Gentoo doesn't "pick" any build backend version. They build each Python project exactly the way the project owner tells them to, using whatever build backend is specified in pyproject.toml for that project. That's why it's such a burden for them (or more precisely their users, since each Gentoo user is having to do this) if build backend versions change so often and projects don't pin a specific version but just say "use the latest"--because then they have to use what the project owner says, and the project owner says, "Update to a new build backend every week because that's how often my chosen backend, uv-build, likes to push updates".

This coordination problem is already solved by PyPI. That's where Gentoo looks to find the build backend--just like everyone else that builds packages. The project owner had to be able to find whatever version they used there or they couldn't even build their project locally. So they should be able to depend on the fact that anyone else trying to build their project can also find that same version at the same place.

> getting every open source maintainer to upgrade their build backend version (whether uv-build, or flit, or anything else) every Tuesday.

You're missing my point. If I know that my project builds properly with build backend X version Y, and I pin that version in my pyproject.toml, I don't care how many newer versions you want to release. Unless I make a change to my project that merits updating my build backend to a newer version, I'm going to simply leave my project alone. I already know it will build fine with the version I have. Why should I push an update every Tuesday just because you decided to release a new version of the build backend, which I don't need anyway?

This wouldn't necessarily solve Gentoo's problem. The only way to be sure to solve Gentoo's problem would be for every Python project that uses uv-build to specify one particular version. Then Gentoo could be sure that once that release of that project was built once, it would never change.

In other words, for a distro like Gentoo, the build backend is a dependency, and if it changes, that triggers a change in the build, even if the build backend change would not actually change the final wheel that got built.

But it isn't. Once upon a time, it was: you used distutils. But of course distutils had a lot of problems. Instead of adopting a single standardized solution for those problems, the Python developers punted and let third parties do it. So now we do not have a single standardized solution for building Python packages; we have a bunch of third party solutions, none of which is in the Python standard library.

Yes, all those third party solutions have to be PEP 517 compatible, but that's not standardization on a tool; it's just standardization on an interface between the backend and the frontend. Which is nice, but doesn't solve the problem under discussion here.

> if uv’s build backend doesn’t fit into the hole you want, then you can use any number of other backends that do an admirable job of conforming to the packaging standards.

As the project developer, sure. But as a Linux distro building your python package, Gentoo has to use the build backend you specify. It can't say, well, this particular package is just pure python, so really all we need is a minimal tool to build a pure python none-any wheel. It has to use the backend you specified.

> I don’t understand why Gentoo needs to rebuild every single release of uv-build.

Because if you don't pin a version of uv-build in your project, that means "use the latest version available". Gentoo can't second guess you--even if it were able to verify somehow that the new version of uv-build that just got released will end up producing an identical wheel for your project as the previous version, without actually using the new version of uv-build.

> you can do a normal version bound in your Python build backend metadata

Sure, but how many users of uv-build actually do that? Seems like the answer to that is "not enough to matter".

One could argue that it isn't, which is why I described the viewpoint as heuristic. It's not intended to be a comprehensive explanation of everything to do with strong interactions. It's just a heuristic way of describing why adding energy to a hadron doesn't help the quarks inside to escape, the way adding energy to an atom can help the electrons inside to escape.

I did say the viewpoint was heuristic. It's quite true that it isn't necessary; you can, as you say, just describe what's going on as adding energy until a quark-antiquark pair is created.

No, in the heuristic approximation you are using here, the strong interaction does not weaken with distance; it strengthens with distance, so it takes more and more energy to try to pull two quarks apart, for example, as they get further apart (whereas the energy it takes to pull, say, an electron and a proton apart gets less and less as they get further apart).

So, for example, if you try to pull apart the quark and antiquark inside a pion, at a distance scale of roughly a femtometer, the energy required to pull the two quarks apart is large enough to create another quark-antiquark pair, and so you end up with two pions. You never get free quarks.

Similar remarks would apply to trying to pull a gluon out of, say, a glueball; you just end up making more gluons and making the glueball larger; you never get free gluons.

And moreover he wasn't at all afraid to say so; he clearly considered it normal and commonplace.

https://note.com/apt_crow7500/n/n440c1a6cfb63?hl=en

No, governments do not spend money on producing cash. They make money by printing it. The net value to the government of printing money is positive, not negative. (And in our current financial system, they distribute much of that value to financial institutions and the rich people who own them--which was the original reason the Federal Reserve system was put in place, due to intensive lobbying by the rich people at the time.)

As I said, the fee you're paying if you use a credit card is for financial intermediation. That's not just "giving someone money" or "collecting money". There are other things included that have significant costs to provide.

> They provide a valuable service

And that means all your rhetoric about "charging a rake", "tax", "parasitic toll collection", "tithe", etc. is misplaced, because those things all imply that there is no valuable service being provided.

If you want to argue that there are ways to reduce the cost of the valuable service, for example by competition, that's one thing. But that's not the argument you're making.

On the contrary, the middlemen in credit card transactions are providing a service whose value add is so obvious that it's basically invisible, because it's become so normal: financial intermediation. The credit card company is basically covering your debts for you until you pay your monthly bill--and shielding you from having to give every merchant you purchase from your bank account information. On the other side of the transaction, the credit card company is guaranteeing payment to the merchant, who now doesn't have to care about trying to assess the financial reliability of every customer. It's become so normal that we don't realize what a huge value add it is, as compared with, for example, trying to convince the grocery store to accept your check, which forces you to hand them your bank account information, and forces them to decide whether they think you (and your bank) are reliable enough that your check isn't rubber.

But in our actual society, false reports are not rare--this case is an illustration of that (55 false reports, no true ones). So, as I said, this logic does not work for our actual society, which is clearly not a high trust society.

Um, no. In a high trust society "swatting" would not be a thing--because people would understand that it's a huge violation of trust. And people who did make hoax calls like this would suffer severe punishment--because that's what a high trust society has to do to people who violate trust like that, in order to stay high trust.

> Act now (to reduce potential loss of life)

Not necessarily, since SWAT teams are generally not noted for their restraint--certainly not if their response on swatting call number 55 to the same house is the same as it was for call number 1.

> and verify later

Okay, let's say this is valid for call number 1. Still, what about call number 2 to the same house? Let alone call number 55? Especially when the owner of the house produces evidence that people had threatened to swat him?

So no, we do not have the kind of society where your logic makes sense; the rare cases where the quick knee jerk response actually prevents harm are more than overwhelmed by the much more common cases where it's a false alarm but the police keep on violating innocent people's rights anyway.

Which does raise the question: why is it SOP for the police to send a SWAT team to a random house based on nothing but an anonymous phone call? At the very least it should take some kind of statement from an actual identified human who can be held accountable if it turns out to be a hoax.