This project is archived and is in readonly mode.
Problem with config.gem and "pure" extensions
-
Wincent Colaiuta
- Title changed from Problem with config.gem and "pure" extensions to PATCH: Problem with config.gem and "pure" extensions
Ok, I believe I've fixed the first issue (exceptions thrown for uninstalled gems) with the patch that I'm going to attach now.
The problem was in the plugins method in railties/lib/rails/plugin/locator.rb:
def plugins specs = initializer.configuration.gems.map(&:specification) specs + Gem.loaded_specs.values.select do |spec| spec.loaded_from && # prune stubs File.exist?(File.join(spec.full_gem_path, "rails", "init.rb")) end require "rubygems/dependency_list" deps = Gem::DependencyList.new deps.add(*specs) unless specs.empty? deps.dependency_order.collect do |spec| Rails::GemPlugin.new(spec) end endWhen we first grab the specs if a required gem isn't installed on the system then we'll end up with an array that looks like "[nil]".
Later on we call deps.add(*specs) because specs.empty? returns true. The nil value then causes dependency_order to choke. The actual backtrace (excerpt) looks like this:
rake aborted! undefined method `dependencies' for nil:NilClass /Library/Ruby/Site/1.8/rubygems/dependency_list.rb:139:in `tsort_each_child' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/tsort.rb:204:in `each_strongly_connected_component_from' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/tsort.rb:183:in `each_strongly_connected_component' /Library/Ruby/Site/1.8/rubygems/dependency_list.rb:133:in `each' /Library/Ruby/Site/1.8/rubygems/dependency_list.rb:133:in `tsort_each_node' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/tsort.rb:181:in `each_strongly_connected_component' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/tsort.rb:165:in `strongly_connected_components' /Library/Ruby/Site/1.8/rubygems/dependency_list.rb:46:in `dependency_order' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/rails/plugin/locator.rb:92:in `plugins' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/rails/plugin/loader.rb:63:in `locate_plugins' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/rails/plugin/loader.rb:62:in `map' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/rails/plugin/loader.rb:62:in `locate_plugins' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/rails/plugin/loader.rb:27:in `all_plugins' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/rails/plugin/loader.rb:22:in `plugins' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/rails/plugin/loader.rb:45:in `add_plugin_load_paths' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/initializer.rb:229:in `add_plugin_load_paths' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/initializer.rb:112:in `process' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/initializer.rb:89:in `send' /Users/wincent/trabajo/unversioned/wincent.com/src/config/../vendor/rails/railties/lib/initializer.rb:89:in `run' /Users/wincent/trabajo/unversioned/wincent.com/src/config/environment.rb:7So anyway, the attached patch avoids that problem by filtering out nil values from the specs array.
-
Wincent Colaiuta
Ok, attaching another patch which fixes the other problem by adding the "ext" subdirectory inside the frozen gem for those gems which have it.
-
Wincent Colaiuta
Yet another patch. This one applies on top of the previous patch, although I can make a patch which instead applies on top of the current "master" if desired.
The problem is that we are appending frozen gems to the load path rather than prepending them. This means that if user freezes version "X" into "vendor/gems" but the system already has version "Y" then we will incorrectly end up loading "Y" instead of the desired "X". The solution is to prepend rather than append, to ensure that the frozen gem takes priority.
-
Wincent Colaiuta
Forget patch 1 of the series. I see an equivalent fix has already been committed here:
-
Pratik
- Title changed from PATCH: Problem with config.gem and "pure" extensions to Problem with config.gem and "pure" extensions
-
Pratik
- Assigned user set to Rick
-
Repository
- State changed from new to resolved
(from [71528b1825ce5184b23d09f923cb72f4073ce8ed]) Previously we only added the "lib" subdirectory to the load path when
setting up gem dependencies for frozen gems. Now we add the "ext"
subdirectory as well for those gems which have compiled C extensions
as well. [Wincent Colaiuta]
[#268 state:resolved]
