Stack trace makes it hard to discern real errors

[Alan Pope 🍺🐧🐱 🦄]

Can we please make the display of stack traces in snapcraft an option which is off by default. It's really not a pleasant experience to have an entire 1080p terminal screen full of python trace to discover a simple typo or mistake in a yaml.

I get this, just because I didn't mention the source-type for example.

Traceback (most recent call last):
  File "/snap/snapcraft/1008/bin/snapcraft", line 11, in <module>
    load_entry_point('snapcraft==2.38', 'console_scripts', 'snapcraft')()
  File "/snap/snapcraft/1008/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 565, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/snap/snapcraft/1008/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2631, in load_entry_point
    return ep.load()
  File "/snap/snapcraft/1008/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2291, in load
    return self.resolve()
  File "/snap/snapcraft/1008/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2297, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/cli/__main__.py", line 19, in <module>
    run(prog_name='snapcraft')
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/click/core.py", line 1043, in invoke
    return Command.invoke(self, ctx)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/cli/__init__.py", line 124, in run
    ctx.forward(lifecyclecli.commands['snap'])
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/click/core.py", line 553, in forward
    return self.invoke(cmd, **kwargs)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/cli/lifecycle.py", line 136, in snap
    container_config, output, directory)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/lifecycle/_containers.py", line 43, in containerbuild
    config = project_loader.load_config(project_options)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/project_loader/__init__.py", line 25, in load_config
    return Config(project_options)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/project_loader/_config.py", line 131, in __init__
    snapcraft_yaml=self.snapcraft_yaml_path)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/project_loader/_parts_config.py", line 56, in __init__
    self._process_parts()
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/project_loader/_parts_config.py", line 86, in _process_parts
    self.load_part(part_name, plugin_name, properties)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/project_loader/_parts_config.py", line 196, in load_part
    confinement=self._confinement)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/__init__.py", line 94, in __init__
    self._part_properties)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/__init__.py", line 130, in _get_source_handler
    self._source, source_type=properties['source-type'])
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/sources/__init__.py", line 161, in get_source_handler
    source_type = _get_source_type_from_uri(source)
  File "/snap/snapcraft/1008/lib/python3.6/site-packages/snapcraft/internal/sources/__init__.py", line 189, in _get_source_type_from_uri
    raise ValueError('no handler to manage source ({})'.format(source))
ValueError: no handler to manage source (https://bitbucket.org/klembot/twinejs)

[Kyle Fazzari (kyrofa)]

> Can we please make the display of stack traces in snapcraft an option which is off by default.

We have this type of behavior on our roadmap, but there's quite a bit of work to be done yet.

> It's really not a pleasant experience to have an entire 1080p terminal screen full of python trace to discover a simple typo or mistake in a yaml.
>
> I get this, just because I didn't mention the source-type for example.

Agreed, although the fix to this bug is not the roadmap issue of changing our CLI interface, but rather introducing a new error class to handle this case instead of raising a ValueError (which will stop a traceback from appearing).

[Evan (ev)]

I thought the plan was to use Rollbar (or equivalent) and turn off stack trace reporting. That was my understanding coming out of New York. Has the plan changed?

[Kyle Fazzari (kyrofa)]

I'm not sure that we settled on Rollbar, but yes, like I said, this is on the roadmap. It has not yet been prioritized, however, and this specific issue (an unhandled source) is one that should be fixed with a real error, not a ValueError.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

I think we're missing the wood for the trees here.

I get these stack trace errors _all_ the time. Not just this error, not just this /type/ of error. When snapcraft falls over for whatever reason, I _always_ seem to get a stacktrace. That's what this bug is about, not this specific error.

What this bug is about, is the fact that snapcraft sprays out stuff which to me, as a snapcraft user (not developer) is uninteresting and hinders my ability to see what actual error I should be fixing. I'd like the error message to be clean and simple, and not preceded by 20-30 lines of python, if possible :)

[Kyle Fazzari (kyrofa)]

Fair enough. We can leave this bug to track the roadmap CLI changes. I'd still like to see bug reports about tracebacks that should not be tracebacks, though. I'll log another bug about this particular one.

[Matthew Paul Thomas (mpt)]

At the Summit this week I suggested a “snapcraft traceback” or similar command that would show the most recent traceback. That way, even when they were off by default, you could still retrieve the last one for pasting into a bug report.

[Gustavo Niemeyer (niemeyer)]

This sort of problem should be very high priority. It hits everybody all the time, provides a feeling of overall flakiness and lack of care, and it should be trivial to fix. We really don't need 10 different engineers saying the same thing.

[Gustavo Niemeyer (niemeyer)]

FWIW, independently reported:

https://forum.snapcraft.io/t/taming-error-handling-in-snapcraft/3877/3