On Thu, 2006-04-20 at 11:33 +0100, Guido van Rossum wrote:
Unfortunately, this is mixed in with some stuff that isn't part of distutils' "core competency", like text utilities, process spawning, and option parsing. These should (eventually, when the 2.1 compatibility requirement is lifted) be refactored to use (or be merged into) the available stdlib facilities for such functionaliy.
With today's svn repo, I don't think there's any need to force Python 2.5's version to pay for the backward compatibility with earlier versions. This is what I do with the email package for example. In the sandbox, I have externals to Python 2.3's version for email 2.5, Python 2.4's version for email 3.0, and Python 2.5's version for email 4.0. Yes, it's more work to maintain three branches, but it's manageable. So it's not due to lack of structural support that we have to keep forward porting a package's baggage, but only the distutils/setuptools maintainers can decide whether it's too much work to maintain multiple branches. And there's a lot of joy to be derived from removing lots of backward compatibility crap. (It's always more fun to remove code than add new code :). At some point you have to move on. Python 2.1 and 2.2 are getting increasingly difficult to support, and I've found less and less call for it from my users. OTOH, Python 2.3 is still very popular, so that's now my minimum requirement. -Barry