Python build backends are standardized in PEP 517, and packaging metadata is standardized in PEP 621. You can read the actual metadata PEPs for “computed” metadata i.e. the metadata that appears in distributions as well, if you’d like.

(It’s not kind or charitable to call someone a liar.)

▲

231ag 2 hours ago | parent [-]

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 an hour 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.
	▲	BigTTYGothGF an hour 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.