Logging to stdout and bzr selftest
Martin Pool
martinpool at gmail.com
Mon Sep 12 06:46:18 BST 2005
On 12/09/05, Robert Collins <robertc at robertcollins.net> wrote:
> On Fri, 2005-09-09 at 22:09 +0000, Brian M. Carlson wrote:
> > When running "bzr selftest", the code prints lots of unnecessary junk to
> > the screen. A patch against r1189 is attached to use the logging
> > mechanism instead. It causes no regressions.
Thanks for noticing and for sending a patch. As Robert says we are
trying to move away from this strategy of capturing stdout, and
instead make the library not write directly to stout.
> Hi, we deliberately removed a similar mechanism: bzr library calls
> should not print anything to stdout/stderr anyway, and all the runbzr
> calls that test the front end do their own redirection inside the test.
>
> What we want to do is ensure that any library violations of the output
> guidelines in HACKING are noticed quickly :).
In other words, the correct fix is to change the commit code to either
write out through logging, or make it return an object containing the
summary. I'll do that second thing now because I'm working on the
commit code.
> > BTW, sorry about the modeline, but vim is not currently set up to do
> > PEP-8 compliant code, and that's the only way that it will.
>
> I don't know what Martins thoughts are about modelines - I quite like
> them - but they can be very contentious :0. Martin ?
I don't mind them as long as they're reasonably small, and people
agree on what's in them. Certainly much better than inconsistent
style. If the vim heads think this is right then maybe we should add
it to all files?
> I have the following in my ~/.vimrc to handle non-modeline marked files.
> autocmd BufRead *.py set sts=4
> autocmd BufRead *.py set sta
> autocmd BufRead *.py set et
> autocmd BufRead *.py set ai
> autocmd BufRead *.py set shiftwidth=4
> autocmd BufNewFile,BufRead *.py match Error /^[[:tab:]]\+/
--
Martin
More information about the bazaar
mailing list