Latest post is a big one: “Why you shouldn’t invoke setup.py directly”
A lot of people don’t know about this because we haven’t been great about getting the word out. This blog post is in part an attempt to remedy this.
Please help spread the word!
https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html
@pganssle I admit that Python's packaging and building story is the area of Python where I've struggled the most since starting with it. Reading your post shows me there's more work I need to do, but I do appreciate the effort of writing it all up in a place that I can come back to later. Thank you for writing it.
@pganssle one thing: so why bother with setuptools while it is in fact another "hot mess of legacy code"?
Do you have some examples (maybe it's another post?) of:
> These will generate out-of-date metadata files and packages based on old standards, holding back the evolution of the ecosystem.
(I have a distutils project of a C extension to move it to something better)
@saper In my experience, a lot of the new class of build tools are optimized for making life easier for projects on the “happy path” — simple scripts and pure python projects, etc.
For C extensions or other niche applications, the best supported option is probably still setuptools
.
@saper As for the other question, the following paragraph, “If it ain’t broke?” explains how the old upload
endpoint was uploading bad metadata.
There’s also PEP 643, which will really help clean up dependency resolution when setuptools
gets supported for it if people are using recent versions of setuptools
.