Honestly, this is where things get a little blurry, but I believe what solved this first problem was a manual patch to engine.rb in the railties-4.0.0.beta1 gem. For RVM users you can do the following to find the source location for that gem:
The manual change I made was based on this gist, which I found from this issue. Long story short, I made that change, ran my rake command again, and got a new error. I wasn’t out of the woods completely, but I’d made progress. The new error looked like this:
bundleexecrakerails4:check_gemsrakeaborted!uninitializedconstantRails::SubTestTask/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/rails-perftest-0.0.1/lib/rails/perftest/railties/testing.tasks:2:in`block in '/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/rails-perftest-0.0.1/lib/rails/perftest/railties/testing.tasks:1:in `'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/rails-perftest-0.0.1/lib/rails/perftest/railtie.rb:8:in `block in '/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/railtie.rb:201:in`instance_exec'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/railtie.rb:201:in `blockinrun_tasks_blocks'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/railtie.rb:201:in `each'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/railtie.rb:201:in`run_tasks_blocks'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/application.rb:241:in `blockinrun_tasks_blocks'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/engine/railties.rb:17:in `each'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/engine/railties.rb:17:in`each'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/application.rb:241:in `run_tasks_blocks'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/engine.rb:445:in `load_tasks'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/gems/railties-4.0.0.beta1/lib/rails/railtie/configurable.rb:30:in`method_missing'/Users/adam/src/sandbox/screencast/Rakefile:7:in `'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/bin/ruby_noexec_wrapper:14:in `eval'/Users/adam/.rvm/gems/ruby-2.0.0-p0@rails4/bin/ruby_noexec_wrapper:14:in`'(See full trace by running task with --trace)
At that point, I decided to hold off on fixing rake, and move on to seeing if I could run rails s. The result was better than expected, but still not clean.
I did some research, then ultimately made a handful of changes to development.rb, production.rb, test.rb, and application.rb. I found that creating a fresh Rails 4 app, then comparing each of those files from the new app to those on my existing app, was really helpful. I’m not going to include the exact changes I made to those files because I don’t want to lead anyone down the wrong path, but the most import changes were: removing whiny_nils configs, adding eager_loading configs, and removing the active_record.auto_explain_threshold_in_seconds config. I also started with a new application.rb based on the fresh rails4 app, then added back my non-standard configs to that.
I then tried the rake command again, and sure enough, it worked. The change to application.rb had fixed that problem.
At this point, ‘rails s’ and ‘rake’ were both working and the app was running fine. This is great progress, but I still hadn’t fully converted my app to Rails 4 code. I’ll cover that progress in a series of followup posts. The first step was using binstubs.