alt Hacker NewsEach 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.
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.