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.
[0]: There should be one-- and preferably only one --obvious way to do it. (from the zen of python)