Re: [Distutils] I browsed through the distutils source!

Hi Greg, sorry , didn't have time to look at this yet .. just a question/suggestion What I really like about Makefiles is the -n mode where I can see what it would do before it actually does it. Is duch an option available in setup.py and if not could it be added. Cheers -Michel On Mar 30, 2:01pm, Greg Ward wrote:
report on what happened.
There's not much to running it; from the top distutils directory, do:
./setup.py build
should work pretty much anywhere. A slightly more risky proposition is
./setup.py install
which relies on distutils.sysconfig to get the installation directories; it in turn relies on finding Python's Makefiles in the usual place. I have no idea if they're even installed under Win 95 -- please let me know!
Greg, anything you'd like me to examine especially?
The weak spots! Search for "XXX" in the code; I'm liberal with X-rated comments. Also check my "Current weaknesses" post from last night; see if you can correlate my opinions of current problems with the code.
When it occurs to you that commands are a lot like subroutines, and then when you start to wonder why parameter passing is done backwards, then you'll be up to speed. (The whole problem of communicating options between commands was bigger than I expected. The implementation isn't overly complicated, but I think it'll take some bouncing around across various classes and thinking about the alternatives before it becomes apparent why I did it that way.)
Oh, the big reason I put the code up now is this: I think it's close to being at a state where development can be in parallel. The basic framework is in place, all that's missing is a lot of commands to do the work. The beginnings of building and installation are in place, and I've started thinking about the 'build_ext' command -- witness the thread on compiler abstraction models. But the "dist" and "bdist" commands -- to create source and built distributions -- are important and could easily be done by someone else.
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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig
-- End of excerpt from Greg Ward

Quoth Michel Sanner, on 30 March 1999:
sorry , didn't have time to look at this yet .. just a question/suggestion What I really like about Makefiles is the -n mode where I can see what it would do before it actually does it. Is duch an option available in setup.py and if not could it be added.
Yes, the option is there, but support for it is rather spotty. The idea is something like this (from the top distutils directory): ./setup.py -nv build or, equivalently, ./setup.py --dry-run --verbose build But the "dry run" option is ignored at the moment -- I'll explain below. Currently, verbose mode is *not* the default, even if you specify "dry-run" mode. (Thus "./setup.py -n build" will do nothing silently.) This is probably wrong, and trivial to fix; but first I need to figure out just how much information the default verbosity level should give. Currently it reports every filesystem interaction (just copying and compiling so far), which might be a bit much for the default but must be available as an option. Hence some notion of "verbosity level" is probably needed. The other tricky thing is to make sure that all command classes respect both the "verbose" and "dry run" options. Verbosity is handled by the 'announce()' method in the 'Distribution' and 'Command' classes; "dry run" mode is not currently handled very well. (It's the responsibility of each command class to get the "dry_run" flag from the Distribution object and obey it, which I think is too much to ask. For instance, if you look at the build_py command, you'll note that I seem to have completely forgotten about handling "dry run" mode, which is why the above commands don't work -- they go right ahead and build Distutils anyways, despite the -n option.) I see two ways to do this nicely, both of which involve bundling up a "filesystem operation" as a couple of discrete objects -- function to to call, arguments for it, and descriptive string to print. The simpler way is to pass this bundle to a function which prints the message if the current verbosity level is high enough, and calls the supplied function if we're not in dry-run mode. The 'make_file()' function (in distutils.util) is vaguely in this direction, except it doesn't have access to the verbose and dry_run flags (needs the Distribution instance for that). Also, it adds the notion of input and output files and simple timestamp dependency checking -- which is why it's called "make_file"! Handy, but it adds excess functionality to the simple notion of "do this thing now, respecting the verbose and dry-run flags". The other, somewhat less obvious, way to handle the dry-run (and verbose) flag is to save all these "do this thing now" bundles in a list. Then, when we have run *all* commands, walk through the list and carry out the planned operations. I don't think this extra complication is really needed in the Distutils, where most runs should be over in a second or two, and even the biggest builds/installs should only take a few minutes. It's a very useful scheme when you're writing glorified shell scripts that will run for many many hours, cranking through the analysis of large datasets (which is what I did a lot of in a previous life -- I know a thing or two about writing glorified shell scripts, and some of that knowledge seems applicable in the Distutils). 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
participants (2)
-
Greg Ward
-
Michel Sanner