$LOAD_PATH issue with Ruby 1.8.7 and Rails 2.2.2?

I started a thread over on rails-talk (http://groups.google.com/group/ rubyonrails-talk/browse_thread/thread/e799165794ea0052) but got no responses, and am a little concerned this might be an issue with Ruby 1.8.7 and Rails 2.2.2, if only because I can't eliminate any other possibilities yet.

Here's the story: shortly after upgrading my Slice server from Ubuntu 8.04 to 8.10 - which upgraded Ruby to 1.8.7 along the way - I found that I couldn't start up my app anymore. The app was frozen to 2.1, and after realizing the Ruby upgrade, I re-froze to 2.2. Still wouldn't work; doing a script/about yields this error message:

/home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/action_view/ template_handler.rb:11:in `initialize':ArgumentError: wrong number of arguments (0 for 1)

After much trial and error, I came to notice that the $LOAD_PATH is a bit messed up; the server app does not have the following in the $LOAD_PATH like my local app does:

../vendor/rails/railties/builtin/rails_info/

Not sure why this would explain the error, but I'm trying to figure out why I'd get that strange error when the only difference I can see is a change from 1.8.6 to 1.8.7. I've tried switching from frozen Rails to 2.2.2 gems but it made no difference.

Any ideas/insights/suggestions would be very welcome, this is driving me nuts; if this is surely not a Rails bug, then I'll continue on the rails-talk list instead.

Thanks Jeff

Sounds more like an issue where you have mismatching framework versions. You should have posted the full stack trace. Does every line come from vendored rails, or did some framework load accidentally from a gem?

> /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/action_view/ > template_handler.rb:11:in `initialize':ArgumentError: wrong number of > arguments (0 for 1)

Sounds more like an issue where you have mismatching framework versions. You should have posted the full stack trace. Does every line come from vendored rails, or did some framework load accidentally from a gem?

Thanks! I think you're onto something... the whole stack trace is below, but now I see that rake rails:update did not update the scripts; so it still had my 2.1 version of script/about, wheres the 2.2 version explicitly adds the rails_info directory to the load path.

Methinks many other things didn't get updated, either. What's the "right" way to make sure everything gets updated to 2.2.2?

Here's the whole stack trace I get when trying to start script/server, for example - maybe I'm missing something obvious?

(purple) current: script/server => Booting Thin (use 'script/server webrick' to force WEBrick) => Rails 2.2.2 application starting on http://0.0.0.0:3000 => Ctrl-C to shutdown server

Using rails adapter

Exiting /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/action_view/ template_handler.rb:11:in `initialize': wrong number of arguments (0 for 1) (ArgumentError)   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/template_handler.rb:11:in `new'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/template_handler.rb:11:in `call'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/renderable.rb:21:in `_unmemoized_compiled_source'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:57:in `compiled_source'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:25:in `__send__'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:25:in `memoize_all'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:22:in `each'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:22:in `memoize_all'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:17:in `freeze'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:88:in `reload!'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:102:in `templates_in_path'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:100:in `each'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:100:in `templates_in_path'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:86:in `reload!'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:78:in `load'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:109:in `load'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:109:in `each'   from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:109:in `load'   from ./script/../config/../vendor/rails/railties/lib/initializer.rb: 357:in `load_view_paths'   from ./script/../config/../vendor/rails/railties/lib/initializer.rb: 182:in `process'   from ./script/../config/../vendor/rails/railties/lib/initializer.rb: 112:in `send'   from ./script/../config/../vendor/rails/railties/lib/initializer.rb: 112:in `run'   from /home/jcohen/sites/pw/current/config/environment.rb:13   from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'   from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:153:in `require'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:521:in `new_constants_in'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:153:in `require'   from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/rack/adapter/rails.rb: 31:in `load_application'   from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/rack/adapter/rails.rb: 23:in `initialize'   from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/rack/adapter/ loader.rb:36:in `new'   from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/rack/adapter/ loader.rb:36:in `for'   from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/controllers/ controller.rb:163:in `load_adapter'   from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/controllers/ controller.rb:67:in `start'   from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:173:in `send'   from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:173:in `run_command'   from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:139:in `run!'   from /home/jcohen/sites/pw/current/vendor/rails/railties/lib/commands/ servers/thin.rb:20   from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'   from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:153:in `require'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:521:in `new_constants_in'   from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:153:in `require'   from /home/jcohen/sites/pw/current/vendor/rails/railties/lib/commands/ server.rb:49   from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'   from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'   from script/server:3

Thanks again! Jeff

Just in case anyone cares and to close this thread, part of the solution involved changing the code in my custom template handler. Seems like 2.2 broke 2.x syntax for custom handlers.

It used to be that you had to declare your handler with an initializer like this:

class MyHandler < ActionPack::TemplateHandler

def initialize(view)   @view = view end

end

Now, the initializer must not accept any arguments at all:

def initialize end

(or you can just leave it out altogether, of course).

This wasn't the only problem I had when I refroze my 2.1 app to 2.2, but I thought I'd mention it in case it trips up anyone else. I didn't see this mentioned in the release notes or changelogs anywhere.

To be fair, Josh did mention template refactoring in the 2.2 ActionView changelog, but maybe in the future it would be better to deprecate major changes for a release first.

Thanks Jeff

The 2.0 → 2.2 road has been VERY bumpy regarding the ActionView API, especially internal ones. I’m not sure if what you subclassed is considered a public or internal API. I remembered having fixed unit tests for Haml or will_paginate ActionView integration many times.

But now ActionView codebase is significantly cleaner, which shows all that refactoring has paid off. The only question left to answer is: what defines an API of a Rails component public or private? Having documentation?

The 2.0 -> 2.2 road has been VERY bumpy regarding the ActionView API, especially internal ones. I'm not sure if what you subclassed is considered a public or internal API. I remembered having fixed unit tests for Haml or will_paginate ActionView integration many times.

Good point - I thought that the TemplateHandler stuff was considered public. If not, it should be, especially now that Josh has worked hard on making it nicer - I think being able to write your own custom "builder" is pretty compelling.

But now ActionView codebase is significantly cleaner, which shows all that refactoring has paid off. The only question left to answer is: what defines an API of a Rails component public or private? Having documentation?

I might be wrong, but I didn't notice any :nodoc: labels anywhere in the template handler classes, just a lack of RDoc-style comments. I think explicitly using :nodoc: is a good way to indicate that it's internal, or at least "depend on this at your own risk."

Jeff