Merge lp:~mbp/bzr/499637-default-uifactory into lp:bzr
| Status: | Merged |
|---|---|
| Approved by: | John A Meinel on 2010-01-14 |
| Approved revision: | 4961 |
| Merged at revision: | not available |
| Proposed branch: | lp:~mbp/bzr/499637-default-uifactory |
| Merge into: | lp:bzr |
| Diff against target: |
81 lines (+29/-8) 3 files modified
NEWS (+5/-0) bzrlib/tests/per_uifactory/__init__.py (+4/-7) bzrlib/ui/__init__.py (+20/-1) |
| To merge this branch: | bzr merge lp:~mbp/bzr/499637-default-uifactory |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| John A Meinel | 2010-01-14 | Approve on 2010-01-14 | |
|
Review via email:
|
|||
| Martin Pool (mbp) wrote : | # |
| Martin Pool (mbp) wrote : | # |
Despite the name I haven't fixed bug 449637 here yet, because it causes a somewhat annoying circular import situation to try to set bzrlib.
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
> Despite the name I haven't fixed bug 449637 here yet, because it causes a somewhat annoying circular import situation to try to set bzrlib.
>
The bug states that the problem is that SilentUIFactory gives a
make_output_stream error. Is there something else going on that I don't
understand?
main() is the helper that sets the ui factory and trace settings. I
think it is reasonable that if someone wants to call 'run_bzr' directly,
they can set things up for themselves. (Otherwise they would call
main(), right?)
Anyway, your change is ok. I think it *does* break people who would be
using run_bzr() directly (without setting a ui_factory). Think of stuff
like run_bzr('diff'). It used to output content to sys.stdout even
without the ui_factory set. However, I can understand that Silent seems
to indicate that there wouldn't be any output.
Though if they are already running things directly, they also have to do
stuff like "install_
doing this works and produces output:
from bzrlib import commands
commands.
commands.
However on bzr.dev it produces a "make_output_stream not supported"
error. With your patch it succeeds, but produces no output.
Not failing is better than failing on every command (even ones that
don't produce output, or don't produce it through make_output_
I'd be slightly happier if we continued to produce output, but only a bit.
John
=:->
review: approve
merge: approve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt
tC0AoJZNkA1X6Lk
=qGMk
-----END PGP SIGNATURE-----
| Martin Pool (mbp) wrote : | # |
2010/1/15 John Arbash Meinel <email address hidden>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin Pool wrote:
>> Despite the name I haven't fixed bug 449637 here yet, because it causes a somewhat annoying circular import situation to try to set bzrlib.
>>
>
> The bug states that the problem is that SilentUIFactory gives a
> make_output_stream error. Is there something else going on that I don't
> understand?
There are two bugs here:
1- silentuifactory
reasonable for it to discard the output
2- the default for bzrlib should probably be text output to
stdout/stderr, as it once was, not silence
#2 was once mostly working because bulk output didn't go through the
uifactory. However, other things that did go through the uifactory
didn't work by default in the way you would have expected. So what's
changed there is just that the scope of the uifactory has grown so the
consequences of not setting one are larger.
This fixes #1; I'd like to fix the second too but it's a bit annoying
to get something from a submodule to initialize a variable in a
supermodule at load time because of circular import restrictions.
> main() is the helper that sets the ui factory and trace settings. I
> think it is reasonable that if someone wants to call 'run_bzr' directly,
> they can set things up for themselves. (Otherwise they would call
> main(), right?)
I think calling main() directly has always worked. The other case is
people just using arbitrary internal bzrlib functions.
> Anyway, your change is ok. I think it *does* break people who would be
> using run_bzr() directly (without setting a ui_factory). Think of stuff
> like run_bzr('diff'). It used to output content to sys.stdout even
> without the ui_factory set. However, I can understand that Silent seems
> to indicate that there wouldn't be any output.
>
> Though if they are already running things directly, they also have to do
> stuff like "install_
> doing this works and produces output:
>
> from bzrlib import commands
> commands.
> commands.
>
> However on bzr.dev it produces a "make_output_stream not supported"
> error. With your patch it succeeds, but produces no output.
So if I don't fix #2 above, they will need to call
make_ui_
which is reasonable but I think not ideal.
> Not failing is better than failing on every command (even ones that
> don't produce output, or don't produce it through make_output_
> I'd be slightly happier if we continued to produce output, but only a bit.
--
Martin <http://
| Martin Pool (mbp) wrote : | # |
https:/

This fixes https:/ /bugs.edge. launchpad. net/bzr/ +bug/499757 by making SilentUIFactory accept make_output_stream