I've looked around a bit and didn't find similar errors reported.
I don't recall having modified my production.rb
. And for good measure, here's my application.rb
Here's the stack trace from Heroku.
$ heroku run rake db:migrate --remote staging --trace
Running rake db:migrate --trace attached to terminal... 开发者_开发百科up, run.2
/app/vendor/bundle/ruby/1.9.1/gems/rack-1.3.4/lib/rack/backports/uri/common_192.rb:53: warning: already initialized constant WFKV_
rake aborted!
undefined method `sass' for #<Rails::Application::Configuration:0x000000047c6fb0>
/app/vendor/bundle/ruby/1.9.1/gems/railties-3.1.1/lib/rails/railtie/configuration.rb:78:in `method_missing'
/app/config/application.rb:63:in `<class:Application>'
/app/config/application.rb:18:in `<module:Instantice>'
/app/config/application.rb:17:in `<top (required)>'
/app/Rakefile:5:in `require'
/app/Rakefile:5:in `<top (required)>'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/lib/rake/rake_module.rb:25:in `load'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/lib/rake/rake_module.rb:25:in `load_rakefile'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/lib/rake/application.rb:495:in `raw_load_rakefile'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/lib/rake/application.rb:78:in `block in load_rakefile'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/lib/rake/application.rb:77:in `load_rakefile'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/lib/rake/application.rb:61:in `block in run'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/lib/rake/application.rb:59:in `run'
/app/vendor/bundle/ruby/1.9.1/gems/rake-0.9.2/bin/rake:32:in `<top (required)>'
/app/vendor/bundle/ruby/1.9.1/bin/rake:19:in `load'
/app/vendor/bundle/ruby/1.9.1/bin/rake:19:in `<main>'
I initially thought this line in the application.rb
could be causing this (although it never had before).
config.sass.preferred_syntax = :sass
Removing it was fruitless though.
I had the same error...
I just needed to move the gem 'sass-rails'
out of the assets group
Was
#Gemfile
group :assets do
gem 'sass-rails' # Was giving me errors here.
...
end
Is
#Gemfile
gem 'sass-rails' # No more errors
group :assets do
...
end
I spent the entire day yesterday troubleshooting this and managed to fix it.
I did remove the config.sass.preferred_syntax
line but it wasn't the only issue.
Most importantly I was missing what seems like a crucial require statement for Sprockets.
Since I'm using RSpec I had commented split up the usual require "rails/all"
line in my application.rb file into this:
require "active_record/railtie"
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
# require "rails/test_unit/railtie"
I can only guess that was an oversight when I upgraded from Rails 3.x to 3.1.x. The correct statement should include Sprockets, as follows:
require "active_record/railtie"
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
# require "rails/test_unit/railtie"
require "sprockets/railtie"
I also removed some Compass settings I had gleaned a Chris Eppstein Gist on using Compass with 3.1. It was a desperate move but for now I haven't seen any downsides.
Bear in mind, I had no idea what I was doing. Take this with a grain of salt, I'm simply explaining my "debugging" process.
I found a better way to resolve this if you are also upgrade from a rails 3.0 project: Just change the lines in config/application.rb from
Bundler.require(:default, Rails.env) if defined?(Bundler)
to
if defined?(Bundler)
# If you precompile assets before deploying to production, use this line
Bundler.require(*Rails.groups(:assets => %w(development test)))
# If you want your assets lazily compiled in production, use this line
# Bundler.require(:default, :assets, Rails.env)
end
精彩评论