Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

Rails 2.3.5 GemPlugins get not loaded #83

Closed
d--j opened this issue Feb 16, 2010 · 24 comments
Closed

Rails 2.3.5 GemPlugins get not loaded #83

d--j opened this issue Feb 16, 2010 · 24 comments

Comments

@d--j
Copy link

d--j commented Feb 16, 2010

to fix this, use Gist 305262

@indirect
Copy link
Member

I am using haml, rspec-rails, and authlogic with my Rails 2.3.5 app. Everything seems to be working. What isn't working for you?

@uniglam
Copy link

uniglam commented Feb 16, 2010

indirect, what version of haml are you using? I'm getting Missing Template errors that look as if haml is not being found.

@d--j
Copy link
Author

d--j commented Feb 16, 2010

For me it's devise, declarative_authorization, delayed_job and simple-navigation that isn't working. All gems that have engines (like devise) should need this fix. Some gems that depent on their rails/init.rb or init.rb file beeing loaded should need it, too.

@indirect
Copy link
Member

Thanks. I'll test it and then get the gist updated tonight after work.

@indirect
Copy link
Member

Guys, I'm testing this out, and my init.rb files are definitely getting loaded without d--j's boot.rb patch. Could you gist your preinitializer.rb, boot.rb, Gemfile, and tell me what version of bundler you are using, and whether you are locked or not?

@jasonm
Copy link

jasonm commented Feb 17, 2010

the boot.rb patch helps some, but not all the way. Without the boot patch, I can't load rails engine http://github.com/mbleigh/twitter-auth - error: https://gist.github.com/be6fcb3260ce525bbda8

With the boot patch, twitter-auth loads, but a shoulda helper from the paperclip gem does not:

https://gist.github.com/5bbc547220f5af212fe0

which is provided by http://github.com/thoughtbot/paperclip/blob/master/shoulda_macros/paperclip.rb . If I manually require that file, everything seems to work OK (with the patch to boot.rb).

@trevorturk
Copy link

+1 the gist at the top of this thread seems to have solved my issue:

http://github.com/carlhuda/bundler/issues#issue/87

See also, this Google Groups thread about Heroku and bundler 0.9:

http://groups.google.com/group/heroku/browse_thread/thread/f786f5b32558fdf1

Maybe the strategy put forward in that gist (or something similar) should be included in the bundler readme? I'm encouraging Heroku to consider updating their docs once this is all sorted out, too.

@indirect
Copy link
Member

I am happy to include it if one of you can help me reproduce the problem. I have now spent three hours of my own time on three different Rails apps, setting up bundled gem plugins. They all work.

I have an old app that uses Haml (among other) gem plugins. It works. I created a new app and bundled twitter-auth, and it works too. If you have an example where it doesn't work until you apply the boot.rb patch from d--j, please gist:

  • The command you run to generate the exception
  • The exception backtrace
  • Whether you have locked or not
  • What version of bundler you are using
  • Your Gemfile
  • Your boot.rb file
  • Your preinitializer.rb file
  • Your environment.rb file

If someone could supply that, and I can verify that the patch is needed to use gem plugins, I will apply the patch to my gist. Thanks.

@jasonm
Copy link

jasonm commented Feb 17, 2010

Hi indirect,

I've added the following repo with no .gitignore that reproduces the issue:

http://github.com/jasonm/bundler-test

See the file http://github.com/jasonm/bundler-test/blob/master/console-session-demonstrating-issue for a console session demonstrating the issue by running script/about, with backtrace. The same exception is raised during script/console, and script/server.

I'm using ruby "ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10.2.0], MBARI 0x6770, Ruby Enterprise Edition 2009.10" with rails 2.3.5, and bundler 0.9.6.

Thanks!

@indirect
Copy link
Member

Thanks. I'll test this tonight. In the meantime, I have just added code that should fix the issue to the main gist at http://gist.github.com/302406

@trevorturk
Copy link

@indirect, I'm still having a problem with your gist and rails gem engines. I've saved a terminal session that demostrates @d--j's gist working, and yours not working:

https://gist.github.com/3ec4a92f7057c0fbdf43

I've included a diff at the end showing the difference as well. I believe if you follow those steps, you should be able to reproduce the problem.

Please let me know if I can be of any more help, and thanks for your time working on this. I know it's got to be frustrating ;)

I also might consider re-opening this issue, as I'm not sure it's been completely resolved.

@indirect
Copy link
Member

@trevorturk thank you for the example app, it has made the issue very apparent. You must run any rails script via the bundler. For example, bundle exec ./script/about. If you do that, gem plugins are automatically loaded, and everything works. If you do not do that, nothing is guaranteed, and things other than just the gem plugins are likely to be broken.

Since it seems that the readme is not clear enough about bundle exec being required, I will try to make it more clear.

This issue is resolved: run all commands in a bundled app via bundle exec.

@indirect
Copy link
Member

I should clarify: ./script/about and friends are actually supposed to work while the bundle is locked. However, that is a bug in bundler, and should not be fixed with a monkeypatch to Rails in boot.rb.

A ticket has been filed for the bundler locking bug as issue #92. Thanks.

@trevorturk
Copy link

Sorry, but I'm still confused. It sounds to me like you're saying:

a) until issue #92 is resolved, your gist is still recommended over d--j's (perhaps you can clarify why?) and we have to prefix commands like "./script/about" with "bundle exec"

b) when issue #92 is resolved, your gist will still be necessary

c) when issue #92 is resolved, locking your bundle will still be necessary

d) when issue #92 is resolved, commands like "./script/about" will no longer need to be prefixed with "bundle exec"

Is that correct?

@indirect
Copy link
Member

a) You are free to use d--j's gist, of course. I'm not going to add another rails monkeypatch to mine to work around a bundler bug when you can already work around it by just running bundle unlock, or prefixing your commands with bundle exec.

b) My gist will remain necessary unless a version of rails 2.3.x is released with bundler 0.9 support baked in.

c) Locking your bundle is not necessary now and will not be necessary after #92 is fixed.

d) You can simply bundle unlock, and ./script/about will work, right now. If you want to stay locked, you can run bundle exec ./script/about, right now. Once #92 is fixed, you will be able to stay locked and run ./script/about without bundle exec.

@trevorturk
Copy link

That's great. Thanks very much for the clarification, and for your attention to this issue.

@trevorturk
Copy link

FWIW - I tried to switch to the recommended technique in the README after 0.9.7 but it seems that the Devise gem is not being loaded. So, I'm just going to use the gist from d--j for now, since that seems to work for my apps.

@indirect
Copy link
Member

I checked out jasonm/bundler-test, and 0.9.7 does in fact fix the issue he reported. If you would like me to troubleshoot your issue with Devise, please gist:

  • The command you run to generate the exception
  • The exception backtrace
  • Whether you have locked or not
  • What version of bundler you are using
  • Your Gemfile
  • Your boot.rb file
  • Your preinitializer.rb file
  • Your environment.rb file

@trevorturk
Copy link

Here's a gist that shows everything you're asking about:

https://gist.github.com/64f8688dc7fd1f2ce9a6

Hopefully, you should be able to follow along and reproduce the problem on your side. This may be a problem with gem-plugins, but I'm not sure.

Thanks again for your attention to this problem, and let me know if I can help at all.

@d--j
Copy link
Author

d--j commented Feb 19, 2010

I updated my gist so that it works with bundler 0.9.7 (in locked and unlocked mode)

I also made a test repository with this fix applied: http://github.com/d--j/bundle-devise-test - here you can see that it is needed, just clone it, disable the fix in boot.rb and try to run e.g. script/about

I don't think that you can fix the problem on the side of bundler. You will always need this fix or also define the used gems in environment.rb (at least the gems that (a) need their rails/init.rb to be executed or (b) need to be put in the auto-load path of rails)

@d--j
Copy link
Author

d--j commented Feb 19, 2010

I was wrong. After some sleep and some digging I realized that it's the fault of devise that it does not get setup properly as a GemPlugin. devise only has an init.rb, not a rails/init.rb. Rails::Plugin::GemLocator only finds GemPlugins if they have a rails/init.rb file.

I updated my gist again to also search for init.rb and will open an issue with the devise project.
When devise (and possibly other GemPlugins out there) has a rails/init.rb, your gist, indirect, will be all that is needed. Until then I stick with mokey patching Rails::Plugin::GemLocator#plugins

@d--j
Copy link
Author

d--j commented Feb 19, 2010

@indirect
Copy link
Member

Great. Thanks for letting me know. I'll add a note to my gist so people will be aware of the issue.

@indirect
Copy link
Member

@d--j, I've added a comment in the Gemfile telling people to use git for devise until 1.0.3. If you have any other problems/suggestions, let me know.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants