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

Add support for IRB-alternatives (Pry and Ripl) to `bundle console`. #1616

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
Contributor

postmodern commented Jan 8, 2012

No description provided.

hannesg commented Jan 8, 2012

+1

haarts commented Apr 13, 2012

+1

This pull request fails (merged 9f40691 into 7f7f7c0).

👍

👍

Contributor

rohit commented Dec 4, 2012

I'm a bit confused. How are you picking which console to start? Are you just picking the one that's available based on the order you've specified? Wouldn't it be better to have an option to bundle console? Defaulting to IRB and allowing the user to pass an argument specifying which console to start. Accordingly you'd need to change the thor command docs and the man pages too IIRC.

I think this is a decent enough feature to be included in Bundler. @indirect, @hone would this be desirable?

+1

Contributor

spangenberg commented Dec 26, 2012

+1

Owner

indirect commented Feb 15, 2013

I don't want to force people into using pry, ripl, or irb, in that order, depending on what gems they have installed. Why not just create a shell alias for bundle exec ripl? Same effect, much less effort. :)

ches commented Feb 15, 2013

@indirect Not quite the same effect: it also leaves you to require 'my-in-progress-gem' every time you load up the console. Even with readline history this gets tiresome.

Owner

indirect commented Feb 15, 2013

Well, while I might accept a setting or argument to change the console, I'm not going to accept a patch that forces the pry console on anyone who's ever installed a bundle with pry in it. Sorry. :\

ches commented Feb 15, 2013

@indirect I think your point is completely reasonable, a setting seems sensible.

In the long run it'd be nice if Bundler didn't have to be updated to support new alternatives, but would you be willing to keep the require-to-constant mapping for the time being so that the configuration is simple for users? I.e. I could just bundle config console pry and Bundler would know the constant to load. Or maybe someone sees another way without requiring an awkward config value for the option (Bundler could provide a hook for REPL authors to register their lib if defined? Bundler maybe).

Owner

indirect commented Feb 15, 2013

I think adding a config option, and trying to require that config option, then falling back on IRB with a warning if the require fails, should do it. How about you?

Contributor

joallard commented Jun 24, 2013

Sounds good

Owner

indirect commented Aug 4, 2013

Closing this as rejected. Totally willing to merge a patch that adds bundle config console FOO though.

@indirect indirect closed this Aug 4, 2013

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