Add --onsigint handler, run on KeyboardInterrupt

[blueyed]

This gets run on KeyboardInterrupt/SIGINT, which could be sent by a
--beforerun script, which kills all child processes (i.e. any
currently running py.test instance).

This also introduces the explicit "failed" state, which is not "not
passed" with py.test.

[blueyed]

My wrapper script: https://github.com/blueyed/dotfiles/blob/master/usr/bin/ptw-watch-tests

(Yes, it screams for using --runner instead, but it's older already.. :))

It will make use of tmux window title colors.

[blueyed]

btw: exit codes are documented (and importable from _pytest.main) at http://pytest.org/latest/_modules/_pytest/main.html.

[blueyed]

Hmm, py.test also uses interrupted with -x:

Interrupted: stopping after 1 failures

This should get handled as a failure..

[decentral1se]

[joeyespo]

This looks good! Nice find on the importable exit codes, @blueyed.

@lwm Thanks for the bump!

[joeyespo]

@blueyed I'm thinking of releasing the CLI arg under a different name. sigint is a bit technical. What do you think of --oninterrupt, which is similar to KeyboardInterrupt and pytest's EXIT_INTERRUPTED?

[blueyed]

@joeyespo
Sure, go ahead. But KeyboardInterrupt is really Python specific for SIGINT though (and a bit misleading).

btw: there were some squash! commits meant to be - well - squashed..
So, get your Picard facepalm pictures out.. ;)

[joeyespo]

@blueyed 😄

[joeyespo]

Awesome. Renamed in 7d9516f.

[joeyespo]

Poking around with this today, I noticed with the else, onexit will never get called (unless there was a problem with ptw). I think onexit should always be called regardless, since that's its intention.

Why couldn't you have used onexit before?

[blueyed]

@joeyespo

Why couldn't you have used onexit before?

The use case here is to be called when the process is interrupted (and then kill its children / running py.test).
I see that this could be handled better in general, but was the way to go when seeing the existing handlers.

[joeyespo]

Since ptw runs indefinitely, the only way onexit will be called is if the process is interrupted. So would that work for you?

[blueyed]

You're right probably, and I've been using the other interrupt handler then only (https://github.com/joeyespo/pytest-watch/pull/46/files#diff-298efc967591604e348416060d077075R129).
Feel free to fix / enhance.

[joeyespo]

Ok cool. Thanks!

I'm currently rewriting some of the logic so that only one instance of py.test gets run at a time. Just wanted to make sure I'm not stepping on your toes with a specific case I didn't know about.

[joeyespo]

FYI, 4.0 was just published. It contains a slightly more abstract --afterrun option as opposed to --onsigint or --oninterrupt. It gets run after pytest completes or gets interrupted by a re-run. It also receives the exit code from pytest, so it can compliment any initialization done by --beforerun, or perform some more advanced logic based on the exit code.

For running code when you interrupt ptw (or your --beforerun script does) and cause it to exit, use --onexit instead.

Feel free to open a new issue if this doesn't cover all the bases.

[blueyed]

@joeyespo
It works great, thanks!
The only "downside" is that a script is required now.
Maybe some printf-replacement could be done on the --afterrun argument?
(e.g. '%d' would be replaced by the exit code?!)
Or, what about setting some environment variable (PTW_EXIT_CODE), that can be looked at by the command?

[joeyespo]

Thanks!

What do you mean by "script"? As in --afterrun "one && two" won't work? That's a good point. I hadn't thought of that case until you said something.

An ENV variable seems reasonable. It's self-contained, flexible, can be the first of more, and would be just as much work for a script to access it than a CLI argument. Can you think of any downsides?