If I could "cvs up" I would submit a patch, but in the meantime, is there any good reason that distutils shouldn't write its output to stderr? I'm using PyInline to execute a little bit of C code that returns some information about the system to the calling Python code. This code then sends some output to stdout. I've patched my local directory tree so that distutils sends its output to sys.stderr. Is there some overriding reason distutils messages should go to sys.stdout? BTW, Python + PyInline makes a hell of a lot easier to understand configure script... ;-) Skip
[Skip Montanaro]
If I could "cvs up" I would submit a patch, but in the meantime, is there any good reason that distutils shouldn't write its output to stderr?
Win9X (command.com) users can't redirect stderr, and the DOS box there has a 50-line maximum output history. So stuff going to stderr is often lost forever. stdout can be redirected. I don't know whether disutils had that in mind, but it is "a reason" to leave it alone.
I'm using PyInline to execute a little bit of C code that returns some information about the system to the calling Python code. This code then sends some output to stdout.
If there's a connection between this and disutils, it's not apparent from what you wrote.
Tim> Win9X (command.com) users can't redirect stderr, and the DOS box Tim> there has a 50-line maximum output history. So stuff going to Tim> stderr is often lost forever. stdout can be redirected. I don't Tim> know whether disutils had that in mind, but it is "a reason" to Tim> leave it alone. Perhaps it would be friendlier if all distutils messages were hidden in "if verbose:" statements (many already are). PyInline could then dial down the verbosity before calling distutils. >> I'm using PyInline to execute a little bit of C code that returns >> some information about the system to the calling Python code. This >> code then sends some output to stdout. Tim> If there's a connection between this and disutils, it's not Tim> apparent from what you wrote. Sorry about the missing link. PyInline uses distutils to compile the C code. How PyInline does its think doesn't really matter to me, so I'm not going to be interested in distutils' messages. Skip
[Skip]
Sorry about the missing link. PyInline uses distutils to compile the C code. How PyInline does its think doesn't really matter to me, so I'm not going to be interested in distutils' messages.
If distutils output isn't interesting to PyInline users, shouldn't PyInline be changed to run setup.py with its -q/--quiet option?
"TP" == Tim Peters <tim.one@home.com> writes:
TP> [Skip]
Sorry about the missing link. PyInline uses distutils to compile the C code. How PyInline does its think doesn't really matter to me, so I'm not going to be interested in distutils' messages.
TP> If distutils output isn't interesting to PyInline users, TP> shouldn't PyInline be changed to run setup.py with its TP> -q/--quiet option? 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 code has no consistent way of generating messages or of interpreting the notion of verbose or quiet. I think the right solution is to have several levels of verbosity and have a single function or method to use for output. (Perhaps a print statement with appropriate >>.) This makes it easier to control the amount of information you get and where it gets printed to. Michael Hudson has signed up to implement it and whatever else we can pile on when he's not looking. Further discussion should probably go to the sig. Jeremy
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. 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. 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. Greg -- Greg Ward - programmer-at-big gward@python.net http://starship.python.net/~gward/ "He's dead, Jim. You get his tricorder and I'll grab his wallet."
"GW" == Greg Ward <gward@python.net> writes:
GW> Oh wait: most of the low-level worker code in the Distutils GW> falls outside the main class hierarchy, so the verbose flag GW> isn't *quite* so readily available; it gets passed in to a heck GW> of a lot of functions. Crap. I wish it were so clean and simple, Greg <wink>. In a lot of places, the binary verbose flag that is stored in the main class hierarchy is compared to some a var named "level". The result of that comparison is passed to functions, which ignore it and just use print. At least sometimes. Jeremy
Tim> If distutils output isn't interesting to PyInline users, shouldn't Tim> PyInline be changed to run setup.py with its -q/--quiet option? Probably so, but not all prints are guarded by "if verbose:". Skip
[Tim]
If distutils output isn't interesting to PyInline users, shouldn't PyInline be changed to run setup.py with its -q/--quiet option?
[Skip]
Probably so, but not all prints are guarded by "if verbose:".
Have you tried it in the case you complained about at the start of this? These days I routinely build elaborate pieces of Zope using -q, and the only msgs I ever see then are things like """ MultiMapping.c Creating library build\temp.win32-2.3\Release\MultiMapping.lib and object build\temp.win32-2.3\Release\MultiMapping.exp """ I believe those are generated by Microsoft's compiler (the case-sensitive string "Creating" appears nohwere in the distutils source; and yes, these go to stdout too), and if so there's nothing distutils can do about that. I don't see any messages that look like they come from distutils. just-because-you-don't-understand-the-code-doesn't-mean-it-doesn't- do-what-you-want<wink>-ly y'rs - tim
Tim> [Skip] >> Probably so, but not all prints are guarded by "if verbose:". Tim> Have you tried it in the case you complained about at the start of Tim> this? Yes, and it seems to shut things up just fine. I made that comment after having modified my source to dump all prints to stderr. Tim> MultiMapping.c Tim> Creating library build\temp.win32-2.3\Release\MultiMapping.lib and object Tim> build\temp.win32-2.3\Release\MultiMapping.exp Tim> I believe those are generated by Microsoft's compiler (the Tim> case-sensitive string "Creating" appears nohwere in the distutils Tim> source; and yes, these go to stdout too), and if so there's nothing Tim> distutils can do about that. I don't see any messages that look Tim> like they come from distutils. Windows matters little to me for most applications, and not at all when I write scripts that I want to work like Unix filters, which is what my original complaint was about. I will suggest to Ken Simpson that PyInline use the -q flag. Thx, Skip
On 31 January 2002, Skip Montanaro said:
If I could "cvs up" I would submit a patch, but in the meantime, is there any good reason that distutils shouldn't write its output to stderr? I'm using PyInline to execute a little bit of C code that returns some information about the system to the calling Python code. This code then sends some output to stdout.
Because stderr is for error messages. Most of the noise generated by the Distutils is optional, here's-what-I'm-doing-now stuff -- ie. *not* errors. If there are Distutils messages that are not silenced with -q, that's a bug (and probably pretty easy to fix, too). Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ All of science is either physics or stamp collecting.
participants (6)
-
barry＠zope.com -
Greg Ward -
Jeremy Hylton -
Jeremy Hylton -
Skip Montanaro -
Tim Peters