Right, but the community is different than the foundation. I would like an authoritative "this is how you do it" doc, from the foundation, about setup/packaging/dist, and I want it to work. And if said doc advises using some third party tool, then the foundation needs to fund or take over maintenance of that tool so that it continues to work and the "standard" way of doing it doesn't change every year.
There have been like three or four iterations of the "here's the official way to package and distribute python code" document. Here's the latest: https://packaging.python.org/
I've seen that before, but I dunno, it seems kind of anti-python[0] to have an "official doc" that basically says "here's a third-party tool we like, but also here's 5 other tools you could use instead." I want ONE tool, built and maintained by the same people who build and maintain python, so that it always works.
[0]: There should be one-- and preferably only one --obvious way to do it. (from the zen of python)
That’s never been true for packages. Just because someone else did it doesn’t mean you can’t do it better. The goal in the last few years has been to make it possible for anyone to write a build system or tooling, just like any other library in Python. Otherwise there is no innovation.
I maintain a library implemented mostly in python with some simple cpython extension modules for performance. Since you can't run unit tests against an extension module before you've built it, my Makefile invokes setup.py just to get things compiled:
python setup.py build_ext --inplace
I don't see a valid replacement for this invocation, but fortunately, it's the only one.
When I include the library from a project that uses it, the same `pip install' command that brings the library in also performs all the compilation described by my setup.py.
All I'd need to move away from deprecated syntax entirely is a way to build the module when I'm testing it within it's own source directory. Until then I won't be changing anything.
It's less crazy than you think. The foundation historically never had developer employees (today has just 1 - a CPython core developer that started 3 months ago). The only way taking over a project and making it de facto standard would be to have (IMHO at least) 5 full time employees working on it. That's a big investment the foundation doesn't have and no corporation commited to support that (for at least 3-4 years). Also, there's the huge backlash the PSF would have to deal with from people who inevitable don't like the choosen standard.
I used to recommend articles with titles like "modern Python package structure and tooling" to graduates. I stopped because the tools (poetry, pipenv etc) were changing so much. I try to fit as much of our workflows into hand made templates and PyCharm now.
There was a post here a while ago about packaging or virtual environments. Within a few minutes, there were quite a few responses about better ways to do it.
Unfortunately, each response had a different recommendation. I wish I could find that thread again.
We have been talking about how to support customers who want to use python. At least for me it isn't very appealing, seems like it could take a lot of attention to keep up with what's expected.
The difference between the community adopting a "standard", and something becoming the standard/being included into the langage by a direct decree is enormous. Especially with Python's philosophy.
The Python community has adopted or created a standard way of doing things for the (checks calendar) fourth or fifth time now.