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. > 1. 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. > 2. 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). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
