Greg Ward <gward@python.net> writes:
On 31 January 2002, Jeremy Hylton said:
I started a thread on similar issues on the distutils-sig mailing list a week or two ago. There's agreement that output is a problem.
The amount of output, or the binary nature of control (total silence vs. total verbosity)? I knew that was a minor problem when I wrote that code initially, but had bigger fish to fry.
I'm thinking that verbose should range from about -2 (no output at all, even from commands if we can supress it) to about 2 (stupid amounts of output) with the default being 0, where we take our guide from what make outputs by default. -v and -q would then be additive on the command line, so python setup.py -q -v -v -q -q would be an odd way of specifying "verbose==-1".
FWIW, my current thinking is that code that wants to be chatty should do something like this:
log(1, "installing foo.bar package") ... log(2, "copying foo/bar/baz.py to /usr/local/lib/python2.1/site-packages/foo/bar")
The first number is the logging threshold, compared against a global verbosity level.
This sounds good.
In a strongly OO system like the Distutils, that should probably be spelled
log(N, msg)
where the logging threshold is carried around in each object (or in some global object).
This shouldn't be too hard to bolt onto the existing code -- ISTR that the verbose flag is readily available to every object in the system; just change it from a boolean to an integer and ensure that every log message goes through self.log().
Oh wait: most of the low-level worker code in the Distutils falls outside the main class hierarchy, so the verbose flag isn't *quite* so readily available; it gets passed in to a heck of a lot of functions. Crap.
There are a lot of calls in disutils that go func(...,...,verbose=self.verbose, dry_run=self.dry_run); Would it really be so bad to have a global "verbose" variable in, say, core? (same for dry_run, too). Of course, what I would like is CL-style special variables, but ne'er mind that... -- ARTHUR: Why are there three of you? LINTILLAS: Why is there only one of you? ARTHUR: Er... Could I have notice of that question? -- The Hitch-Hikers Guide to the Galaxy, Episode 11
Michael Hudson wrote:
Greg Ward <gward@python.net> writes:
On 31 January 2002, Jeremy Hylton said:
I started a thread on similar issues on the distutils-sig mailing list a week or two ago. There's agreement that output is a problem.
The amount of output, or the binary nature of control (total silence vs. total verbosity)? I knew that was a minor problem when I wrote that code initially, but had bigger fish to fry.
I'm thinking that verbose should range from about -2 (no output at all, even from commands if we can supress it) to about 2 (stupid amounts of output) with the default being 0, where we take our guide from what make outputs by default.
-v and -q would then be additive on the command line, so
python setup.py -q -v -v -q -q
would be an odd way of specifying "verbose==-1".
That looks like line noise :-)
FWIW, my current thinking is that code that wants to be chatty should do something like this:
log(1, "installing foo.bar package") ... log(2, "copying foo/bar/baz.py to /usr/local/lib/python2.1/site-packages/foo/bar")
The first number is the logging threshold, compared against a global verbosity level.
This sounds good.
Hmm, that's very close to what I have implemented in mx.Log (see the egenix-mx-base package).
In a strongly OO system like the Distutils, that should probably be spelled
log(N, msg)
where the logging threshold is carried around in each object (or in some global object).
This shouldn't be too hard to bolt onto the existing code -- ISTR that the verbose flag is readily available to every object in the system; just change it from a boolean to an integer and ensure that every log message goes through self.log().
Oh wait: most of the low-level worker code in the Distutils falls outside the main class hierarchy, so the verbose flag isn't *quite* so readily available; it gets passed in to a heck of a lot of functions. Crap.
There are a lot of calls in disutils that go
func(...,...,verbose=self.verbose, dry_run=self.dry_run);
Would it really be so bad to have a global "verbose" variable in, say, core? (same for dry_run, too).
Of course, what I would like is CL-style special variables, but ne'er mind that...
FYI, I usually use a package/module scope global logging object for this kind of thing (rather than a function which then looks somewhere for the debug level). Works great. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
I'm thinking that verbose should range from about -2 (no output at all, even from commands if we can supress it) to about 2 (stupid amounts of output) with the default being 0, where we take our guide from what make outputs by default.
I think the point is that Make has a more useful definition of what should be printed in the default case and what shouldn't, and that's the real problem -- not that there aren't enough levels. Fewer levels is actually better, since there are less ways to screw up. :-) The specific problem is that by default you don't want it to blab about all the things it doesn't have to do because they're already done. Make got this right and distutils got it wrong. I could see three levels at most: - verbose, tells you about everything it could do - default, only tells you about things it does and not about things it skips - quiet, only tells you about errors --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, Feb 01, 2002 at 10:48:22AM -0500, Guido van Rossum wrote:
I could see three levels at most:
- verbose, tells you about everything it could do - default, only tells you about things it does and not about things it skips - quiet, only tells you about errors
FYI, The log4j (j==Java) system uses five levels: 1. debug 2. info 3. warn 4. error 5. fatal Application code uses the system something like this (simplified Python translation): # Go through some steps to get a "Logger" singleton object. import log4py log = log4py.getLogger("distutils") # Then you call methods on the 'log' object for the level of message to # write. log.debug("Distutil *could* do BAR.") ... log.info("Distutils is now doing FOO") ... log.warn("Beware, SPAM may not be what you expect.") ... log.error("This is just wrong.") ... log.fatal("This is really bad. Aborting EGGS.") # The 'log' object knows if, say, log.debug() calls should actually # result in any output (because the setup.py option processing sets the # level to print). So, if I use 'python setup.py -q' the print level is # set to "WARN" (or perhaps "ERROR") and only .warn(), .error(), and # .fatal() calls get printed. That is just an idea of how it could be done. You could reduce the logging levels down to three, as Guido suggested. c.f. http://jakarta.apache.org/log4j/docs/index.html Cheers, Trent -- Trent Mick TrentM@ActiveState.com
From: "Trent Mick" <trentm@ActiveState.com>
FYI,
The log4j (j==Java) system uses five levels: 1. debug 2. info 3. warn 4. error 5. fatal
I'm also a very happy user of log4* (although * = C at the moment for me). IMO: The debug and info levels are for the programmer, only warn, error, and fatal are for the user. Thomas
On 01 February 2002, Guido van Rossum said:
I could see three levels at most:
- verbose, tells you about everything it could do
- default, only tells you about things it does and not about things it skips
- quiet, only tells you about errors
+1 from me. The Distutils' current level of verbosity stems from my desire to see exactly what was happening in the code at the development/debugging stage. That's obsolete and should be fixed. I like Guido's idea. Greg -- Greg Ward - Linux weenie gward@python.net http://starship.python.net/~gward/ Jesus Saves -- and you can too, by redeeming these valuable coupons!
On 01 February 2002, Guido van Rossum said: >> - quiet, only tells you about errors And only to stderr, assuming stderr is available. (Can this be detected on Windows?) If you log messages to stdout, scripts that use distutils can't be used as filters. Skip
>> - quiet, only tells you about errors
And only to stderr, assuming stderr is available. (Can this be detected on Windows?)
Depends on what you call available. sys.stderr should always exist.
If you log messages to stdout, scripts that use distutils can't be used as filters.
IMO it would be better if there was a way to give distutils a file where to send output. --Guido van Rossum (home page: http://www.python.org/~guido/)
From: "Guido van Rossum" <guido@python.org>
>> - quiet, only tells you about errors
And only to stderr, assuming stderr is available. (Can this be detected on Windows?)
Depends on what you call available. sys.stderr should always exist.
If you log messages to stdout, scripts that use distutils can't be used as filters.
IMO it would be better if there was a way to give distutils a file where to send output.
One additional annoyance under windows is that MSVC (when compiling) always prints messages to the console (stderr, stdout? not sure) which cannot be suppressed (at least I haven't found a way). Thomas
participants (7)
-
Greg Ward -
Guido van Rossum -
M.-A. Lemburg -
Michael Hudson -
Skip Montanaro -
Thomas Heller -
Trent Mick