search

ConradIrwin / pry-rescue

Start a pry session whenever something goes wrong.
MIT License
852 stars 49 forks source link

bundle exec rescue guard #6

Open rking opened 12 years ago

rking commented 12 years ago

I'm starting to think we don't really need (or want) an auto-rescue snippet in our spec_helper.rbs.

If the above worked, it would be totally sufficient — devs that want rescue would get it, devs that don't, don't even know any rescuing is going on elsewhere.

I had a couple of issues with it, though:

  1. rescue expects its arg to be a relative path, not a $PATH item, so I had to do: bundle exec rescue $(which guard)
  2. Even after that, it doesn't actually rescue. Perhaps a vicious hack is in order?
ConradIrwin commented 12 years ago

We should definitely fix 1.

The rescue wrapper script is currently intended to catch any exceptions that would otherwise kill your program; it might make sense to also make it insert any of the monkeypatches needed into frameworks it supports (like the rspec snippet); but I'd need to think about it a bit more.

The other related question I'm currently pondering is "how automatic should pry-rescue be in rails?". If it's in the Gemfile, should it just be enabled automatically in development; or do we want to make it so that the user do something explicit (like include a rack middleware, or run "rescue rails s") before it actually takes effect. What do you think?

rking commented 12 years ago

Re: "how automatic", my new position is: not at all.

Devs that download your project and run the test suite don't expect to see a pry prompt. Especially when they're first starting with pry-rescue. They'll have some moments where they have a clear enough headspace that they can experiment with a brand new workflow, and other times when they just have to hack a new feature in.

You could, perhaps, advertise the workflow automatically, like check if the tests aren't being run under rescue and puts some URL.

But yeah, I definitely think that the test frameworks should have special handling.

And, now that I think about it, bundle exec rescue guard wouldn't do anything anyway — guard exects a child process.

This is gross, but what if rescue set an env var, PRY_RESCUE=on, and that var, regardless of where it was set from, would enable the automatic catching of test failures?