Phillip J. Eby wrote:
I assumed that it would be more controversial to merge setuptools into distutils, than to provide it as an enhanced alternative.
It is this assumption in setuptools that seems to have guided many design decisions: that it is completely unacceptable to change implementation details, because somebody might rely on them.
I firmly believe that this position is misguided, and that decisions resulting from it should be corrected (over time, of course). Beautiful is better than ugly: if you believe that the distutils code is wrong in some respect, then change it.
Of course, things are more complicated in this approach: you have to actively consider the likelyhood of breakage, and you have to a) clearly document the potential for breakage: the more likely the breakage, the more visible the documentation should be b) try to come up with recommendations for users should the any code actually break: users then want to know how they should change their code so that it works with previous versions of Python still. c) ask for consent in advance to making a potentially-breaking change.
- How to activate or deactivate backward compatibility for packages or
people relying on intimate details of current distutils behaviors
See above: on a case-by-case basis.
- Maintaining the existing version of setuptools to work with Python 2.3
and 2.4, which would not have this integration with the distutils.
One way would be to make another distutils release, and require setuptools users to install this distutils release as a prerequisite.
Another solution would be to fork setuptools, in a pre-2.5 branch and a post-2.5 branch. Over time, the pre-2.5 branch could be abandoned.
A third solution likely exists on a case-by-case basis: conditionalize code inside setuptools, depending on Python version (or other criteria).