3 ms·
Rails bootstrapping is even more complicated than it looks. As Adam noted, at Insoshi we used to use $ rake install The source of this is require 'activ
by mhartl 18y ago
Rails bootstrapping is even more complicated than it looks. As Adam noted, at Insoshi we used to use
$ rake install
The source of this is
require 'active_record'
require 'active_record/fixtures'
desc "Install Insoshi"
task :install => :environment do |t|
Rake::Task["db:migrate"].invoke
Preference.create!
end
But in edge Insoshi, which uses Rails 2.1, we switched to a simple script in order to accommodate the new way to handle gem dependencies:
$ script/install
It looks like this:
#!/usr/bin/env ruby
# Create some files and directories so they won't be created as root.
# This doesn't do the actual installation, since that needs to be done as root.
system("rake gems:install")
# Install the gem dependencies (if any).
system("sudo rake gems:install")
# Run the main install task.
system("rake install")
You can see that it calls the installation Rake task at the end. Why not just put the gems:install task in the Rake task? This seems like it should work:
require 'active_record'
require 'active_record/fixtures'
desc "Install Insoshi"
task :install => :environment do |t|
Rake::Task["gems:install"].invoke
system("sudo rake gems:install")
Rake::Task["db:migrate"].invoke
Preference.create!
end
Unfortunately, running all the Rake tasks together like this fails, since the install task relies on the gem dependencies being met, but they aren't met at the time the environment gets loaded. (If there is a way to force an environment reload inside Rake, that would work, but I don't know how to do that.)
So, to ensure the greatest flexibility, maybe standard installation shouldn't be a Rake task. I admit that feels a bit weird, but unless we can crack the environment reload problem I don't see any other way.