Tarek Ziadé wrote: > On Tue, Nov 10, 2009 at 2:31 AM, David Cournapeau > <da...@ar.media.kyoto-u.ac.jp> wrote: > [..] >> If you want to support a new source/target (say assembler), you need to >> deal at this stage (or use hacks to deal with the new file extension >> you want to deal with, and remove it later...). So you need to copy >> build_ext, you cannot extend it. >> >> If you look at msvccompiler vs msvc9compiler, both compile methods are >> almost the same and copied from each other. > > So here's a refactoring proposal : > > - build_ext doesn't handle a compiler instance anymore (therefore it > doesn't have a "compile_type" anymore) > > - instead, the Extension class handles this compile type > > - right now we have a dict in ccompiler (compiler_class) that has all > the compiler classes. > let's make it extensible through a registery using distutils.cfg > (like the commands) > > so: when build_ext is run, it compiles the Extensions by using this > registery of compilers, and the type of compiler contained in each > extension. It keeps instances in a pool to reuse them if needed/
What is important here is how to add new tools, without touching or impacting distutils in many places. In particular, what distutils expects from a tool should be clearly defined (right now it is implementation defined). Adding cython or assembly support are good use cases to refactor this I think. > You just don't replace a stdlib package with its v2 like that, there > is a deprecation process to have. > > Distutils is not living only through setup.py. It has some public APIs > imported and used by people. I am aware about the usage of distutils: I don't think it has public API, though. It has functions that people use, but it is far from clear what is public from what is private. Many things we do numpy.distutils are clearly dependent on implementation details of distutils. The problem with moving forward distutils is not deprecation, the problem is when you break/remove the old API. At this point, you will break people's code who rely on the old API. If the changes are big enough (as they should be to warrant breaking the old API in the first place), it will require significant effort from distutils API users. So people will see this as a trade-off: does it worth my time to spend time to use the new version of distutils, what will it bring to me ? Without significant new features, this will be difficult. > -1 > > I'm hearing this sometimes. That's what I thought too when I started > to work with Distutils > a year and a half ago. And I couldn't understand Guido when he was saying that > redoing it from scratch would be a mistake. Now I agree with him. IIRC, the main argument was that a new system would mean giving up existing setup.py, but that can be worked around. I don't know whether Guido's opinion has changed since, but he wondered last year wether dropping backward compatibility was an option (http://www.opensubscriber.com/message/distutils-sig@python.org/10291496.html). Otherwise, a new system would look nothing like distutils. One of the main argument to avoid rewrite is that you will end up doing the same mistakes, and old code is more complicated because it has been tested. But here, we know what a good design is like as other languages have vastly superior solutions to this problem. As far as compilation is concerned at least, the distutils knowledge is vastly overblown. First, most of it comes from autoconf on unices. You have the MSVC tools knowledge, but that can be easily reused (in numscons, I added msvc support from the python 2.6 msvc9compiler, this was not difficult). Most other tools are rather obsolete - and if you break any API in distribute there, you will most likely lose them as well anyway (I am thinking about OS/2, Metrowerk kind of tools). Again, I don't mean to say that working on distribute is a mistake, or criticize what you do in any way. I just don't think it will solve any significant issue for the scientific python community. But enough "stop-energy": at this point, I will just shut up, and continue working on my own idea - if they make sense, the scientific community is big enough so that the solution could be used there only, at least for some time. cheers, David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
