Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

guard-unpry #344

rking opened this Issue Oct 19, 2012 · 6 comments


None yet
2 participants

rking commented Oct 19, 2012

So, if you're hip and stuff, you've been automatically starting Pry within the context of any failing test.

This is super powerful, because for unintentional failures you can cd/ls/$/?/up/down/etc (with pry-stack_explorer and pry-debugger and pry-syntax_hacks, for extra handiness). But you can even take it further by using the REPL to sketch out your implementation and check that it passes the tests, then use edit-method (or even the upcoming save-source) to make your REPLd code permanent on the filesystem.

The downside is that this means you end up with pry sessions sitting around being dumb when you change your test's+impl's externally. This means you have to go Ctrl+d them a lot.

So, I want to make a guard plugin to kill them off according to the same rules as my tests follow in the Guardfile.

I could go poking around and hack something together, but I'd like your input first.

I was picturing a thread that started up and then killed $$ whenever one of the watched files changed.

Any ideas?



netzpirat commented Oct 19, 2012

Another great inspiration. I need some time to add plymouth to Guard and play with it when developing, before I'm able to give some feedback. Thanks a lot.

rking commented Oct 19, 2012

@netzpirat - Cool.

Keep in mind that prying into RSpec failures works, but not perfectly, due to the generated AST looking like RSpec::Core::ExampleGroup::Nested_4. So, figuring out where you are is more of a pain, plus edit -c from Pry will in fact reload the foo_spec.rb, but RSpec will not replace the in-memory spec. You have to kill everything off and let Guard pick up the re-running of the tests (for spec changes, that is. Implementations reload/rerun just fine).

minitest/spec is better w.r.t the AST. It makes predictable methods. But still I'm finding that for live coding you want just Plain Old Classes the way Test::Unit style tests are. E.g. you can do edit -c, fix the test up, then when it exits you can call it by name, like test_bar. Worx grate.

There is a whole frontier, here. Let's blaze a new thing.

rking commented Oct 23, 2012


pry-rescue's git version now allows:

require 'pry-rescue/minitest'

So between this and #350, we're on the trail.

@rking rking referenced this issue in ConradIrwin/pry-rescue Oct 23, 2012


Need guard during prompt #7

rking commented Nov 1, 2012

What about a generic option to guard that makes it spawn a thread while the guard is running, then kills off that process if one of the guarded files changes again?

Would close this issue and would be useful anyway:

  • if you wanted a workflow where you could save a test or impl file and cancel the current test run
  • for the "run all on success" mode (let the individual test pass, then do some more edits and save to kill the run-all)

netzpirat commented Nov 1, 2012

Nice idea, will give it a try...

rking commented Dec 26, 2012

I finally got around to: ConradIrwin/pry-rescue#18

Then one can do something like this, in ~/.vim/ftplugin/ruby.vim:

map <f3> :wa<cr>:!kill-pry-rescue<cr>

One thing that still seems to need fixing is the same as #327 (comment)

I put this in my ~/.guardrc to fix that:

Pry.hooks.get_hook :after_eval, :restore_visiblity or
   Pry.hooks.add_hook :after_eval, :restore_visiblity do system 'stty echo' end

The get_hook check could be removed if the add_hook was done at the right level (it's just that the ~/.guardrc gets re-sourced on each new pry instance, and generates a warning).

I think if the echo part is fixed, this Issue can be closed.

@netzpirat netzpirat closed this in 351a1cf Dec 27, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment