There is a long-term goal to remove setup.py in favor of letting "a thousand flowers bloom". In modern Python setups, the pyproject.toml contains an entry for

There is a long-term goal to remove setup.py in favor of letting "a thousand flowers bloom". In modern Python setups, the pyproject.toml contains an entry for the 'build-backend'. There is a fall-back to 'setuptools.build_meta:__legacy__' because a large number of projects still use setup.py. PyPI recommends hatchling, as the example used in https://packaging.python.org/en/latest/tutorials/packaging-projects/ https://packaging.python.org/en/latest/tutorials/packaging-p... ("You can choose from a number of backends; this tutorial uses Hatchling by default, but it will work identically with setuptools, Flit, PDM, and others that support the [project] table for metadata.") These do not use setup.py. I use setup.py because the new build backends don't seem to support C extensions all that well. My package also has Cython code, and some Python-based code generation for the C code. Another package I know, RDKit, by default automatically downloads missing packages if not available. (These packages are provided as source from the respective authors.) I think distribution people really don't want the build step to be able to run arbitrary code, but they face a long, up-hill battle.