$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