> The setup.py interface makes all this possible, which is why so > many Python packages use it to configure themselves automatically. > > Deprecating this interface would make some distributions impossible > to install without manual user intervention and we'd be back to the > Makefile.pre.in days.
I thought there was a general consensus to move *away* from the need to run setup.py when it's practicable to do so. There was no choice about this with distutils and setuptools, but going forwards, I'm not sure about "impossible to install" as long as *some* mechanism is there for package publisher-defined code to run at installation time. However, setup.py as it is now is a complete free-for-all where anything goes, which I don't think is a good thing. Many PyPI packages are installable with distil (which doesn't use setup.py at installation time), and that includes packages with C extensions, Cython, and even Fortran. The packages distil has problems with are those that do significant things in setup.py, such as moving files around in the source tree, generating new source files, subclassing distutils so you can't see what the actual operations being carried out are, etc. I'm fairly sure that all of these things can be accommodated using installation time-hooks with sensible APIs rather than the ad hoc-ery of setup.py. Of course I'm not suggesting that publishers have to rework existing releases - it's just that the setup.py scheme is a bit archaic and not entirely problem-free. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
