[colpabar]

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.

It seems crazy to me that we don't have this yet.

[qbasic_forever]

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/

[colpabar]

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)

[henryiii]

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.

[monkeybutton]

Innovation or invitation to shave a Yak?

[eesmith]

My use case - distributing a Python package containing Python/C extensions - is described as "Incomplete / Last Reviewed 2013-12-08".

[elevation]

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.

[gaborbernat]

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.