RFC: remove traceback from "newer branch format than your bzr"

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> 2009/8/12 Martin Pool <martinpool at gmail.com>:
>>> apport works on Windows?
>> It's pure Python. It should work there, or at least not be too hard to fix.
> 
> I looked through it a bit.  There is some Linux-specific code, but
> it's segregated and seems to make an effort not to rely on anything OS
> specific.  I'm confident the apport authors would take patches to make
> it work on Windows - and there are some test suites.
> 
>> So it seems to me that if we used Apport it would have these consequences:
> 
> Here's a patch that uses apport to get basically the behaviour Stephen
> and others describe:
> 
> % ./bzr fail
> Bazaar has encountered an internal error:
>     exceptions.AssertionError: fail
> Details have been written to
>     /home/mbp/.cache/bazaar/crash/bzr-20090812093730-7185.crash
> 
> This probably indicates a bug in Bazaar.  You can help us fix it
> by filing a bug report at
>     http://bugs.launchpad.net/bzr/+filebug
> attaching this file, and your own description of the problem.
> 
> The directory is named according to (my memory of) the XDG standard,
> which a bug requests we respect.  Since this is new, we might as well
> use it.
> 
> If apport can't be loaded, we complain and use the previous method of
> writing to stderr.
> 
> I do think it could be cool to interactively ask the user whether they
> want to file the bug report and then automatically kick it off, and to
> do this interaction in a way that is abstracted for GUIs. I think we
> should merge this first though and see how it goes.
> 
> I don't think it's worth worrying about the case of "still running but
> can't write to disk".  It doesn't happen often.  We often are still
> running but can't reach a remote server, but it'd be hard to get to a
> point where local IO can't work.
> 


+def crash_dir():
+    """Return the directory name to store crash files.
+
+    This doesn't implicitly create it.
+
+    On Windows it's in the config directory; elsewhere in the XDG
cache directory.
+    """
+    if sys.platform == 'win32':
+        return osutils.pathjoin(config_dir(), 'Crash')
+    else:
+        return osutils.pathjoin(xdg_cache_dir(), 'crash')
+
+
+def xdg_cache_dir():
+    # XXX: this should probably look at some environment variables too?
+    return osutils.pathjoin(os.path.expanduser('~'),
+        '.cache', 'bazaar')
+
+

^- I'm pretty sure it should look at ENV vars. I also believe that there
is part of the XDG spec to handle things on Windows as well.


For example, this thread:
http://markmail.org/message/tczsbl6y3lm3ss33#query:xdg%20windows+page:1+mid:tczsbl6y3lm3ss33+state:results

Which suggests:
 $APPDATA/XDG/ or if $APPDATA is empty, $HOME/XDG/ (or XDG_CONFIG_HOME)

Anyway, getting slightly more XDG compliant is going to be a bit of
figuring out what the spec really says.

...

+def _open_crash_file():

^- I would probably like to see a big try/except around this in case
something goes wrong while we are trying to report the crash, so we
don't suppress the crash message.

You could be simple, and make it try/except (IOError,OSError), but I'd
probably prefer except: or except Exception:

I realize that might suppress ^C, but we are already in a crash, and I
think we'd still rather get the original failure reported.

...

+    try:
+        from apport.report import Report
+    except ImportError, e:
+        trace.warning("couldn't find apport bug-reporting library: %s" % e)
+        return False

^- Given that we won't have apport on many platforms, I'm not sure that
we want this warning to be shown for all failures. Probably long term we
will, but I don't think we'd want it short term.

I think a lot of this should have more direct tests than you've given it.

'apport' is just a simple dependency at that point, and we can certainly
have tests about what the results of "crash_dir()" return. (Probably
platform specific.)



I think the overall idea is good, and it is something I think we should
land early in a cycle to have both bugs shaken out, and direct developer
experience. It may be that apport is going to be too heavy handed when
developing new code. I also think it likely that we would want a
"debug_flags=noapport" or the equivalent for active development of bzr.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqCwnsACgkQJdeBCYSNAANHTwCeMN1h84jdKdedm8mcnK8YVoKT
irkAoJqRZn7JjdFImpLNqwuuVJH9D6Lk
=BXss
-----END PGP SIGNATURE-----