I don't like setuptools, setup.py nor the directions it evolved to. I will...
#python I don't like setuptools, setup.py nor the directions it evolved to. I will continue to not use setuptools except when some tool only works when you add setup tools into the mix (cython, mypyc) and in that case, I will use something else for the things that don't have to be setuptools.
It is a solution for native code interop developers who have unlimited tolerance for great galloping complexity. That it makes c++ developers happy, I mean, good for them.
Self-replies
Poetry and pipenv both made no particular effort to support native interop and they're better products for it.
For my concerns, if there were two toolchains, one that brings joy to assembler, c, c++ and rust developers and another that brings joy to pure python developers, that would be nice. If other people thought the same, we probably could converge on two popular toolchains.
Getting to 1 package manager to rule them all by asking people to go with the only thing that works will for Fortran (etc) developers means asking pure python developers to put up with a project that has no upper bound on the level of complexity that is allowed to get into DX.