And every backend accepts a different syntax in the .toml file. You cannot just swap out poetry for flit.

Especially when C extensions are involved, everything is entirely unportable. Of course, yet again crabbone is downvoted for speaking the truth.

▲

woodruffw a day ago | parent | next [-]

Each build backend can have its own extensions to the standard packaging metadata. In practice this is common because Python packaging wasn’t designed to solve language ecosystem problems, but to make the union of maintainers, Linux distros, labs, and everybody else who uses Python somewhat happy and able to preserve existing flows.

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.

▲

crabbone a day ago | parent [-]

You pretend not to understand what "packaging" means. No, it's not just the format description, even though the format description incorporates useless fields that are designed specifically to help setuptools to overcome the problems they created for themselves (all the "Dynamic" stuff is worthless otherwise).

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.

▲

woodruffw a day ago | parent [-]

> 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.

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.)

	▲	crabbone 15 hours ago \| parent [-]
		You are absolutely delusional. None of what you write is true. > 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.

▲

BigTTYGothGF a day ago | parent | prev [-]

> Of course, yet again crabbone is downvoted for speaking the truth

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.