After installing the latest rails support packages neither rail, rake or mongel will run: rails test /usr/lib64/ruby/gems/1.8/gems/rails-2.3.10/lib/rails_generator/options.rb:32:in `default_options': undefined method `write_inheritable_attribute' for Rails::Generator::Base:Class (NoMethodError) from /usr/lib64/ruby/gems/1.8/gems/rails-2.3.10/lib/rails_generator/base.rb:90 from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from /usr/lib64/ruby/gems/1.8/gems/rails-2.3.10/lib/rails_generator.rb:37 from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from /usr/lib64/ruby/gems/1.8/gems/rails-2.3.10/bin/rails:15 from /usr/bin/rails:8:in `load' from /usr/bin/rails:8 $ rake routes (in /home/hlandgar/trading) rake aborted! uninitialized constant ActiveSupport::Dependencies script/server => Booting Mongrel => Rails 2.3.10 application starting on http://0.0.0.0:3000 /usr/lib64/ruby/gems/1.8/gems/rails-2.3.10/lib/initializer.rb:249:in `set_autoload_paths': uninitialized constant ActiveSupport::Dependencies (NameError) from /usr/lib64/ruby/gems/1.8/gems/rails-2.3.10/lib/initializer.rb:135:in `process' from /usr/lib64/ruby/gems/1.8/gems/rails-2.3.10/lib/initializer.rb:113:in `send' from /usr/lib64/ruby/gems/1.8/gems/rails-2.3.10/lib/initializer.rb:113:in `run' from /home/hlandgar/trading/config/environment.rb:9 from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from /usr/lib64/ruby/gems/1.8/gems/rails-2.3.10/lib/commands/server.rb:84 from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from script/server:3 Reproducible: Always
I've masked the Rails 3 components until these issues have been fixed.
You should also mask rack-1.2.1 for the same reason. I think we need an eselect for rails modules.
(In reply to comment #2) > You should also mask rack-1.2.1 for the same reason. I think we need an eselect > for rails modules. That's a good idea, masked as well. We already have an eselect module for rails, but I don't think that will help with this situation. I assume that when installing with gems it should be possible to have both Rails 2.3 and Rails 3 running on the same system, so I suspect something in our packaging is causing these problems. My preferred solution would be to install things like rack and rails in slots and remain flexible, but clearly further investigation is needed for that.
It's not clear to me why this happens. My best guess right now is that there is a require somewhere that pulls in activesupport before the framework load path is set up as part of initialization. Advice online seems to be to use bundler or rvm. Vendoring rails might work as well. My own workaround was to explicitly load the right activesupport version in config/boot.rb. Since there are several workarounds and no clear proper solution I'm going to unmask rails 3 despite this bug.
I've found the cause. It's the same problem that we had with rdoc until a few months ago. I filed a bug at http://rubyforge.org/tracker/index.php?func=detail&aid=28758&group_id=627&atid=2472 but they told me that Gentoo was broken. Hans, you patched rdoc, but I'm beginning to think they're right because the solution isn't so simple in this case. rdoc only needed to add its own directory to the path but Rails needs to know the location of several different libraries including ActiveSupport. It seems to be common for Ruby code to rely on the paths that gem dependencies set up and why shouldn't they? That's where all the version information is stored. Why are we so reluctant to rely on RubyGems when Rails (and many other things!) blatantly need it anyway?
To illustrate my point, for Rails 2.3.11, all you need to do is add the following before the "load" line in /usr/bin/rails-2.3.11 and it works. gem "rails", "=2.3.11" Why would we not want to do this for all scripts installed with gems?
(In reply to comment #6) > To illustrate my point, for Rails 2.3.11, all you need to do is add the > following before the "load" line in /usr/bin/rails-2.3.11 and it works. > > gem "rails", "=2.3.11" > > Why would we not want to do this for all scripts installed with gems? This can't really be the cause since a vanilla rubygems installation does not add this line. If we do something different from vanilla rubygems that causes this then we should fix this and match the expected behaviour, but I'm not sure that this is the case here. Some of the ruby scripts in bin also have provisions to load multiple versions of themselves via variables, and adding an explicit gem line would break this.
(In reply to comment #7) > This can't really be the cause since a vanilla rubygems installation does not > add this line. Except it does, at least in a roundabout way! I've never seen it documented anywhere but all the scripts (at least all the ones I've seen) include a snippet like this. version = ">= 0" if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then version = $1 ARGV.shift end gem 'rails', version What this means is that if "rails" is simply called then it will load the latest rails gem. But you can also include a version number if you want an older version like so. # rails -v Rails 2.3.11 # rails _2.3.5_ -v Rails 2.3.5 # rails _2.3.9_ -v Rails 2.3.9 # rails _2.3.11_ -v Rails 2.3.11 I'm guessing we diverged from upstream in this regard, not only because the syntax is a little odd, but also because we have eselect? I prefer our method and I don't think it will cause any problems but it will only work properly if we include that vital "gem" line.
On the subject of eselect, if vanilla rubygems really does do this for every script, maybe we should make a generic "gems" eselect module that handles the scripts for each gem instead of having tons of modules that effectively do the same thing.
Rails 2.3.x was treecleaned a while ago.
