On 02/26/2015 04:49 PM, Dan Smith wrote: ....
What is the point of writing the raw string into the file before we open it? That said, the above should be this for consistency:
Well, it works. The string does make it into the log file.
Sure, but that wasn't the question, the question was: "why?"
Why does it work? No clue! :) Why write it? So when we are handed a log from a user, we know what version it came from. That would be doubly useful if the daily builds munge the version with the build date (which I haven't investigated, so I don't know either way).
It's not a log message because that would end up on the console as well, and we should not unilaterally spam that line at every launch (as that could preclude chirpc from being usable in command pipelines).
Logging at DEBUG level seems appropriate, regardless of where it ends up. So far, you're still relying on the stdout intervention for generating debug.log on Win32, so logging it, having it go to the console, and thus ending up there is appropriate at the moment. When you add a FileHandler for debug.log, you can set that to DEBUG, let the console handler default to INFO, and then you won't see it on the console.
I am not familiar with this "stdout intervention" of which you speak. How do I learn more about it (and turn it off)? That will be required for me to write a complete debug.log handler patch, as we don't want the two features fighting over the same file.
The version should appear in log files regardless of the configured logging level. As far as I can tell, there is no way to do that with the logging module. Conversely, it should never appear on the console.
Presently, the debug.log would only have contained that version string in the GUI (prior to my patches, which removed it). If this is critical, I would say the best immediate solution would be to add it back in the GUI for now. Tonight, I'll write a patch that generates a proper debug.log, and I can remove it again.