Quoth Paul F. Dubois, on 30 March 1999:

Just to chime in about the unmentionable, I have a tool for connecting Fortran and Python (as do others; mine isn't ready for the light of day yet) and unfortunately the existing Setup scheme makes me compile my Fortran separately in a library. I don't have any way to piggyback on what Python has learned about the platform. This is too bad. I am sure it isn't the Python community's job to solve the Fortran 90 make problem but there are days when I dream about it.

The "right" object-oriented approach should allow some way to extend the system, e.g. adding suffices or file names together with info about how to compile them.

The way I see Distutils being extended is by people writing new command classes. Let's say LLNL wants to distribute a Python module with a (shudder) FORTRAN back-end, and Distutils doesn't support FORTRAN. (Sorry, not a lot of call for it.) The general idea, which I have not fully thought through, is that you would write a "BuildFortran" class, and include it with your code -- right there in setup.py if it's not too big. Then, your setup.py would look something like this: class BuildFortran: # ... setup (name = "llnl-fortran-module", version = "1.0", description = "Front end to some crufty FORTRAN code", cmdclass = {build_fortran: BuildFortran}, py_modules = ['mod1', 'mod2'], fortran_extensions = ['fext1', 'fext2']) The part that I haven't really thought through is how the Distribution class is supposed to know that 'fortran_extensions' is a valid option. Perhaps I'll continue to punt on checking options for validity, although it is nice to catch typos! Also, in the current model you'd have to subclass the 'Build' class (which implements -- surprise! -- the 'build' command) so that it calls build_py, build_ext, and build_fortran. Perhaps there should be a mechanism to adjust the "wrapper" commands (currently 'build' and 'install') so they can call more than just the commands hard-coded into them. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

Quoth Greg Stein, on 31 March 1999:

You can also save yourself a lot of time by building something that seems reasonable and waiting for the feedback from people who need it and/or feel it is important.

Umm, that *is* how I'm attacking the problem! I just want to make sure that the design is open enough that people can attack that last 5% (or 10% or 20% or whatever) without running up against the brick wall of a short-sighted design. That's the biggest pitfall of OO: sure it leads to extensible and reusable designs, but only if you carefully build extensibility and reusability into those designs. That's what I'm trying to do with Distutils, and the point of this whole discussion is to get the feedback I need to see if the design is indeed extensible and reusable enough! I think we're in agreement here, except that I'm not even shooting for a 95% job. IMHO getting 90% or 80% of the way there would be enough to build on. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913