Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 347854 - =dev-ruby/activesupport-3.0* breaks dev-ruby/rails-2.3.10
Summary: =dev-ruby/activesupport-3.0* breaks dev-ruby/rails-2.3.10
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gentoo Ruby Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-05 22:47 UTC by Harris Landgarten
Modified: 2014-03-20 03:27 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harris Landgarten 2010-12-05 22:47:38 UTC
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
Comment 1 Hans de Graaff gentoo-dev 2010-12-07 05:08:07 UTC
I've masked the Rails 3 components until these issues have been fixed.
Comment 2 Harris Landgarten 2010-12-07 05:12:41 UTC
You should also mask rack-1.2.1 for the same reason. I think we need an eselect for rails modules.
Comment 3 Hans de Graaff gentoo-dev 2010-12-07 05:19:26 UTC
(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.

Comment 4 Hans de Graaff gentoo-dev 2010-12-28 13:38:59 UTC
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.
Comment 5 James Le Cuirot gentoo-dev 2011-05-05 19:52:18 UTC
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?
Comment 6 James Le Cuirot gentoo-dev 2011-05-05 19:58:34 UTC
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?
Comment 7 Hans de Graaff gentoo-dev 2011-05-08 07:20:11 UTC
(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.
Comment 8 James Le Cuirot gentoo-dev 2011-05-08 12:44:31 UTC
(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.
Comment 9 James Le Cuirot gentoo-dev 2011-05-08 13:53:02 UTC
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.
Comment 10 Manuel Rüger (RETIRED) gentoo-dev 2014-03-20 03:27:44 UTC
Rails 2.3.x was treecleaned a while ago.