(It’s not kind or charitable to call someone a liar.)
Especially when C extensions are involved, everything is entirely unportable. Of course, yet again crabbone is downvoted for speaking the truth.
This is bad for obvious reasons. But it’s not the same thing as Python packaging not being standardized; I would say that Python packaging is as standardized as its user base is willing to stomach. That willingness has grown over the years, to the immense credit of a large group of users who otherwise don’t agree on much.
Packaging, in this context, means a unified interface that describes to the tool what needs to happen to the source code in order for it to be transformed into a binary package. There are about a dozen tools that can package Python binary modules, setuptools, SWIG, bind11 and so on. Each does it in a completely different way. In practice, if you want to build the packages now available on PyPI, you will not be able to come up with a single tool that can build every one of them, probably, not even half of them.
All this talk about standardized metadata is worthless because of what actually goes into the package. The metadata is the least of your problems when packaging Python code.
This is the entire point of build backends, and is no longer true/hasn’t been true for several years. Build backends are not perfect, but they are the reason you can run `uv add` or `pip install` and get a functional wheel from an sdist on PyPI regardless of whether the sdist contains Python, C++, Rust, or anything else.
(This is now the second time you’ve imputed dishonesty in a conversation where I’ve tried to be helpful. So this will be my last response.)
> This is the entire point of build backends
This is false. Python doesn't have any format, any way of describing how to compile a package. There's a gaping void where such a specification should be. Every tool that does it, has its own bespoke way of configuring it. Most of them don't even care what PyPA has to say about it.
> is no longer true/hasn’t been true for several years.
This has been true as recently as this morning. Nothing has changed in the last twenty years, probably more. No change is planned. The people who put themselves in charge of the process are incompetent to the point that, just like you, they don't understand the assignment and produce piles of worthless garbage instead.
> Build backends are not perfect
Build backends is a nonsense invented by PyPA because they didn't understand what actually needs to be done. The whole concept is worthless. It doesn't address the issue: it doesn't have a generic method describing how to build a Python package. Python doesn't need build backends. This whole circus needs to go.
> you can run `uv add` or `pip install` and get a functional wheel
This has nothing to do with building packages. Ideally, these are supposed to install the already built packages. If, however, you accidentally veered into the "oh, crap, I have to build it now because for my platform there isn't a binary", then pip or uv will poop their pants about 50% of the time because the tool that is needed to build the package is not installed, or the dependencies are missing, or the wrong version of the tool is installed, or it's misconfigured etc.
Worse yet, they shouldn't build anything. This is a batshit idiotic idea that a package installer, by default, tries to build a package if a binary is missing. But, we live in the world populated by people without a drop of critical thinking, governed by worshiping tradition, and that's why these tools do what they do.
It wasn't for what was said, but for how it was said, which is why you can say all sorts of heinous stuff on here as long as you're couth about it.
Nobody cares if package metadata is standardized. The tools aren't. The tools are the problem, not the package format.
Well, if the poster says something that is blatantly untrue, how would you call them? Liar describes exactly someone who intentionally tells something that isn't true.