As much as I can see how cathartic it can be to complain about packaging, it’s not clear to me that there’s anything new here. I think almost all of these things are on our radar already, and most of them were discussed at the Python Packaging mini-summit and have specific action items see here.
With regards to the complexity of setuptools, I think that’s largely a documentation issue. Mostly speaking for myself but I think the other setuptools maintainers would agree with this, what we’re looking to do is:
- Make it possible for 90-95% of people to specify their configuration in a declarative metadata file (currently that is
setup.cfg, but we’re happy to also supportpyproject.toml), with first-class support for more complicated workflows insetup.py. - Deprecate and remove the more complicated parts of the
setup.pyworkflow, and getsetuptoolsout of the business of being a command line application. - Move to workflows based on specifications, so that other build tools can be built to those specifications.
The first item on this list is essentially moving closer to how cargo works in Rust - almost everyone specifies their builds in the declarative Cargo.toml, but some small fraction have more complicated builds and have to use build.rs.
That is probably not the correct issue, Issue #1688 has more serious discussion in it, but yes, it is true that if someone is willing to do the work we would almost certainly accept it.