2009/4/6 P.J. Eby <p...@telecommunity.com>: > I mean understanding the use cases and how distutils features are used in > the field.
This is of course true. But quite likely, the only one who does that is you. So it's up to you to document it so others can make solutions that are easy to understand. :) > I agree with you. But I 100% disagree with Tarek that the way to get there > is by refactoring the distutils. The distutils are stable (i.e., dead and > obsolete) and need to be *replaced*, not refactored. One of the language summit conclusions was that many of the features if pkg_resources should make it into the stdlib, and that since distutils was stable, it was probably best to make that a new library. The same problem is true for any new feature in distutils, so quite possibly you are right. We need a "refactored" distutils with new features and with some of pkg_resources in it. And the easiest way to make that so it also works for Python 2.4 etc is to make it a completely new module. This also fixes the current problem with setuptools: That you are one of the few people who actually understand it, which makes you a bottleneck for development. The new module could very well start as a copy/fork of distutils. In fact, it probably should, so that nobody needs to start from scratch. But calling it something else means distribution of it gets easy, and we don't have to worry about backwards compatibility. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig