当在Rails中使用gem时,'无法删除Object :: ClassMethods'是干什么的? [英] When working with gems in Rails, what does 'cannot remove Object::ClassMethods' stem from?
问题描述
有没有人知道这是源于什么?我已经看到了几种不同的情况,但仍然没有知道究竟是什么导致了它。
$ sudo耙宝石:install --trace
pre>
(in / u / app / releases / 20100213003957)
**调用gems:install(first_time)
**调用gems:base(first_time)
**执行宝石:base
**调用环境(first_time)
**执行环境
rake中止!
无法删除Object :: ClassMethods
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in`remove_const'
/ u / app / releases / 20100213003957 / vendor / rails / activesupport / lib / active_support / dependencies.rb:603:在`remove_constant'
/ u / app / releases / 20100213003957 / vendor / rails / activesupport / lib / active_support / dependencies .rb:603:`instance_eval'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in`remove_constant'
/ u / app /releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in`new_constants_in'
/ u / app / releases / 20100213003957 / vendor / rails / activesupport / lib / active_support / dependencies。 rb:549:在`each'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in`new_constants_in'
/ u / app /释放/ 20100213003957 /供应商/轨道/的ActiveSupport / LIB / active_support / dependencies.rb:1 56:在`require'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/misc.rake:4
/usr/lib64/ruby/gems/1.8/gems /rake-0.8.4/lib/rake.rb:617:in`call'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617: in`execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in`each'
/ usr / lib64 / ruby / gems / 1.8 / gems / rake-0.8.4 / lib / rake.rb:612:在`execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake .rb:578:在`invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in`synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake -0.8.4 / lib / rake.rb:571:在`invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in`调用'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/gems.rake:17
/usr/lib64/ruby/gems/1.8/gems/rake-0.8 .4 / lib / rake.rb:617:在`call'中
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in`execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib /rake.rb:612:in`each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in`execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in`invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242: in`synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in`invoke_with_call_chain'
/ usr / lib64 / ruby / gems / 1.8 / gems / rake-0.8.4 / lib / rake.rb:588:在`invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake .rb:585:在'each'中
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in`invoke_prerequisites'
/ usr /lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:in`invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in`同步'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in`invoke_with_call_chain'
/ usr / lib64 / ruby / gems / 1.8 / gems / rake-0.8.4 / lib / rake.rb:564:在`invoke'中
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb :2027:在`invoke_task'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in`top_level'
/usr/lib64/ruby/gems/1.8/ gems / rake-0.8.4 / lib / rake.rb:2005:在`each'中
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005 :在`top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in`standard_exception_handling'
/ usr / lib64 / ruby /gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in`top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/ rake.rb:1977:在`run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in`standard_exception_handling'
/ usr / lib64 / ruby / gems / 1.8 / gems / rake-0.8.4 / lib / rake.rb:1974:在`run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8 .4 / bin / rake:31
/ usr / bin / rake:19:在`load'
/ usr / bin / rake:19
解决方案导致此错误的原因是双重例外。通常,代码中的某些内容会崩溃,这会引发初始异常。然后Rails的定制需要通过移除部分定义的常量来保持名称空间的清洁,这是
new_constants_in
方法的用途。问题在于new_constants_in
没有正确地处理代码中的某个特定构造,我怀疑是由于模块名称空间的错误处理或某事(因为ClassMethods可能位于某个模块之外目的)。在任何情况下,我都没有将错误追溯到Rails组件或其他任何东西,因为坦白地说,这不值得付出努力。
解决方案对Rails核心的侵入性稍微小一点)是一个快速的黑客来找出什么提出了最初的例外。所有你需要做的就是去调用
Dependencies.new_constants_in
并注释掉(这里有几个地方可以)。例如:
def require(file,* extras)#:nodoc:
如果Dependencies.load?
Dependencies.new_constants_in(Object){super}
else
super
end
rescue Exception =>来自所需文件的异常#错误
exception.blame_file! file
raise
end
注释
new_constants_in
stuff:def require(file,* extras)#:nodoc:
#如果Dependencies.load?
#Dependencies.new_constants_in(Object){super}
#else
super
#end
#rescue Exception =>来自所需文件的异常#错误
#exception.blame_file! file
#raise
end
然后你会马上看到你的错误。
Frequently I have run into a problem when installing gems that provides a problem like:
Does anyone know what this stems from? I've seen in it several different cases, yet still haven't learned what exactly is causing it.
$ sudo rake gems:install --trace (in /u/app/releases/20100213003957) ** Invoke gems:install (first_time) ** Invoke gems:base (first_time) ** Execute gems:base ** Invoke environment (first_time) ** Execute environment rake aborted! cannot remove Object::ClassMethods /u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_const' /u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_constant' /u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `instance_eval' /u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_constant' /u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `new_constants_in' /u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `each' /u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `new_constants_in' /u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require' /u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/misc.rake:4 /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain' /usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke' /u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/gems.rake:17 /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain' /usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:588:in `invoke_prerequisites' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `each' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `invoke_prerequisites' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:in `invoke_with_call_chain' /usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2027:in `invoke_task' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `each' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in `top_level' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1977:in `run' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1974:in `run' /usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/bin/rake:31 /usr/bin/rake:19:in `load' /usr/bin/rake:19
解决方案The cause of this error is a double exception. Usually something in your code is crashing, which raises an initial exception. Then Rails' custom require attempts to keep the namespace clean by removing partially defined constants, which is the purpose of the
new_constants_in
method. The problem is thatnew_constants_in
is not properly handling some particular construction somewhere within the code, I suspect due to mishandling of module namespaces or something (because ClassMethods is probably inside some module other than Object). In any case, I have not traced the error back to a Rails component or anything else, because frankly it's not worth the effort.The solution (short of proposing something a little less invasive to Rails core) is a quick hack to figure out what raised the original exception. All you need to do is go to where
Dependencies.new_constants_in
is called and comment it out (there are a few places where this could be). So for example:def require(file, *extras) #:nodoc: if Dependencies.load? Dependencies.new_constants_in(Object) { super } else super end rescue Exception => exception # errors from required file exception.blame_file! file raise end
Comment out the
new_constants_in
stuff:def require(file, *extras) #:nodoc: # if Dependencies.load? # Dependencies.new_constants_in(Object) { super } # else super # end #rescue Exception => exception # errors from required file # exception.blame_file! file # raise end
Then you'll see your error straight away.
这篇关于当在Rails中使用gem时,'无法删除Object :: ClassMethods'是干什么的?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!