Skip to content

Conversation

aanand
Copy link
Contributor

@aanand aanand commented Sep 25, 2015

We don't need the full-blown "here's the code of the massive library method that your error came from" report that py.test gives you by default.

@dnephin
Copy link
Contributor

dnephin commented Sep 25, 2015

If you want to just make this default, you could do this https://pytest.org/latest/customize.html#adding-default-options

@aanand
Copy link
Contributor Author

aanand commented Sep 25, 2015

@dnephin nice, I'll update it

Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
@aanand aanand force-pushed the shorter-stack-traces branch from 3596c5a to 95f42d1 Compare September 25, 2015 18:17
@shin-
Copy link
Contributor

shin- commented Sep 25, 2015

Actually, if something fails, the more verbose the better I think... It's not always useful but I'll take too much information over not enough of it. :x

@dnephin
Copy link
Contributor

dnephin commented Sep 25, 2015

I personally always use --tb=short, you still get the full traceback (filename and line number) for the relevant stack frames, it just doesn't show you the full source for every function.

https://pytest.org/latest/usage.html#modifying-python-traceback-printing

LGTM

@mnowster
Copy link
Contributor

mnowster commented Oct 1, 2015

LGTM

mnowster added a commit that referenced this pull request Oct 1, 2015
@mnowster mnowster merged commit 81bf8e6 into docker:master Oct 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants