-
Notifications
You must be signed in to change notification settings - Fork 49
Control results directory #39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Any comments on regarding this one? |
|
@dopplershift - looks good, but you could you add a test? |
|
Happy to. |
|
Ok, test added. |
|
Same odd failure with 2.x that I can't get locally. |
|
@dopplershift - I'm fixing it in #42. By the way, to reproduce the failure locally you'd likely need to run pytest with the |
|
@dopplershift - can you rebase on the latest master? (I've merged in changes that should fix Travis) |
This makes it easier to find them than looking for a random directory somewhere in /tmp (which is even weirder on osx).
Not only does this seem more fitting, but it permits suppressing the traceback; currently this traceback was only into the pytest-mpl plugin code, so it wasn't very useful at all for users.
20fd471 to
c1edb78
Compare
|
Travis failure on osx with python 2.6 looks spurious. |
|
@dopplershift - sorry for the delay, and thanks for the addition! |
This adds another command line option to specify where results should end up (before the random identifier). That way you can dump them to a location that's easy to get to when things fail.
I also changed
raise Exception(msg)to usingpytest.fail(msg, pytrace=False). The latter better reflects what happens, and withpytrace=Falseit suppresses the traceback, so users don't needlessly see a backtrace into the pytest-mpl plugin code.