[Python-Dev] setuptools in the stdlib ([Python-checkins] r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)

["Martin v. Löwis"]

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