This project is archived and is in readonly mode.
bundle group for addition of custom irb helpers to rails console
Reported by codesnik | February 9th, 2010 @ 07:24 AM | in 3.0.2
now that rails uses Bundler which loads only gems from Gemfile, your lovely .irbrc just doesn't work anymore with "rails console", if you happen to load some gems there.
There's workaround: you can remove your ~/.irbrc (it has a higher precedence) and create "irbrc" in Rails.root, containing just "Bundler.require :console", then create group in your Gemfile
group :console do
gem "every"
gem "wirble"
...
end
this way you don't load thoose gems in rails server or rake tasks, but have them installed and required even in rails console on production servers, which is quite handy in small setups.
but Bundle.require :console could be added to rails console itself, just before loading IRB, and it won't hurt anybody. And then you can drop irbrc in Rails.root if thoose gems do not require additional configuration or initialization.
Comments and changes to this ticket
-
José Valim February 10th, 2010 @ 07:39 AM
- State changed from “new” to “wontfix”
Rails internals does not know anything about bundler. Just your application.
-
codesnik February 10th, 2010 @ 10:52 AM
It seems to me they actually do, railties/lib/rails/backtrace_cleaner.rb for example.
We can use the same trick here, patch attached.Rails console is not a debug tool only, it's an invaluable ready-to-use admin interface for small projects, and it deserves some sugar, no?
-
José Valim February 10th, 2010 @ 11:40 AM
- Milestone cleared.
- State changed from “wontfix” to “open”
- Assigned user set to “Jeremy Kemper”
My concern is, if we do a patch for Bundler, later we would have to make the same for RIP and other packages. For me, it's still a no go, but you definitely have a point if we already have bundler specifics in Rails code, so I'm handling it to Jeremy.
-
codesnik February 10th, 2010 @ 12:22 PM
I understand your concern. There's nothing binding to Bundler or rubygems in the rails code now, apart default generated boot.rb (which could be rewritten for a specific app) and that single bit of bundler in backtrace cleaner is there just because most users would like have that functionality, and adding it by youself is, while possible, not a nobrainer..
..while this patch is essentially equivalent to putting that
Bundler.require(:console)right into your projects irbrc, if you really need it. But I think it would encourage people to create self-contained rails specific irb extensions as gems.And this patch isn't useful without documentation, and I'm not sure where's a place for it, maybe in a default generated Gemfile, commented out, as in the first my patch, would work. or maybe not.
-
Jeremy Kemper February 10th, 2010 @ 04:20 PM
- State changed from “open” to “wontfix”
You can use normal requires in your .irbrc rather than explicit runtime gem dependencies. Not a fan of adding internal Bundler.require(:group) hooks for every case like this.
-
codesnik February 10th, 2010 @ 05:08 PM
actually I can't use "normal requires". If I'm running non customized rails3 generated app, it uses Bundler, and if app uses Bundler, it is initialized before rails console, any .irbrc evaluation, too.
And Bundler empties gem load path, so I can't just
requireany system gem not explicitly listed in app's Gemfile, even in development. I have to create some nondefault group in Gemfile just for that. Thoose gems would be bundled, but won't be loaded while running server.Do you know any other way?
question is, should default group be there for such things, and should I have to create irb.rc in Rails.root even if thoose gems do not require any additional initialization?
(and don't forget that if there's ~/.irbrc, then Rails.root/irb.rc won't load at all. and there's no equivalent for ~/.Gemfile. that sucks)
-
Jeremy Kemper February 10th, 2010 @ 05:21 PM
Put the gems in some group in your Gemfile so they aren't required by default.
Then require them in .irbrc.
-
codesnik February 10th, 2010 @ 07:34 PM
exactly the same solution I've started that ticket with.
Point was, there's is still a great inconvenience ( have to use local project's Gemfile for my "global" ~/.irbrc, and and if i want to use local irb.rc I have to delete global, and whatever ), and I thought some rails-style convenient default for console extensions would compensate for this, though not overcome it.
I'll try to find some another solution, current state is unacceptable for me.
-
Dave Myron July 20th, 2010 @ 06:51 PM
- Importance changed from “” to “Low”
@codesnik: Did you ever figure out a solution for this. I'm getting this same problem with Ruby 1.9.2-head and Rails 3.0.0.beta4
-
codesnik July 21st, 2010 @ 12:16 AM
I wrapped all the gem dependent functionality in my global .irbrc in begin; require 'blabla' .... rescue LoadError; puts "gem blabla not installed"; end blocks.
then if I really need something from that list in my rails console, I add "group :console { gem 'blabla' }" into my project Gemfile.
It's not autorequired, but is available for require anytime.
works for me.
-
Evgeniy Dolzhenko July 21st, 2010 @ 06:06 AM
Probably better place to discuss the issue: http://github.com/carlhuda/bundler/issues#issue/183/comment/225440
-
-
-
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
codesnik
Jeremy Kemper
José Valim
Ryan Bigg