[PATCH] How about a pre-initialization hook in boot.rb?

Oops, got link wrong above, here's ticket #9834

rails_preinitializer_hook_ticket_9943.diff

Cool, I extracted and tested a Rails::Boot after working with your tests for #9834: see [7998].

A simple naming convention like config/initializers/preboot.rb is sufficient and feels appropriate.

Could you show an example of what you'd put in this hook?

Another option is an environment variable pointing to a file or directory to load before boot.

The simplest path for your existing users is to edit environment.rb to require 'myboot' instead which does some setup then requires 'boot' itself.

version 2 of this patch, updated after [7998]

Hi,

Thanks for looking at this. I'll try to answer your questions and point out concerns.

1. An example of what I'd put in this hook, and notes:

  GemInstaller.run(...)
  GemInstaller.autogem(...)

• This would automatically install and load all dependency gems specified in config/geminstaller.yml, including Rails itself. See the detailed GemInstaller docs for more info.
• It's key that this occurs *BEFORE* Rails::GemBoot#load_rails_gem, in order for the preinitialize hook to control the Rails gem version(s).
• Note that this approach is very flexible. It could be used to dynamically determine which versions of any of the Rails gems should be loaded - even locally generated and customized gems.

1. Re: "A simple naming convention like config/initializers/preboot.rb is sufficient and feels appropriate." If you can live with the existence of a default 'config/preinitializers' dir, I think it would be better, because:

1. You don't want the pre-initializer mixed in with the initializers. They do different things - preinit would be doing things like auto-installing and loading gems. You want this done before Initializer, but *NOT* during.
2. To avoid this problem, you'd need extra logic to ignore 'preboot.rb'. Why not just keep it separate?
3. A dedicated config/preinitializers directory would allow multiple, unrelated preinitializer hooks to co-exist and auto-update themselves without worry of interfering with each other or clobbering each other.
4. It would be easier to automate installation of preinit hooks if they can be in a custom named file config/preinitializers/my_hook.rb. Think about the issues faced with installing hook code into a single file. What do I do if it exists? Blow it away? Append?

1. Re: "Another option is an environment variable pointing to a file or directory to load before boot."

• If you point to a file, this has the same issues as the single-hookfile approach mentioned above.
• If you point to a dir, it's a little better. However, this is still "external" to the rails app and not completely self-contained like the config/preinitializers hook dir. The user would have to always ensure they set the environment variable correctly in all scenarios - development, testing, production, etc. It's easier on the users to just know that the existence of a hook in config/preinitializers will always work the same in all situations with no need to set an environment var.

1. Re: "The simplest path for your existing users is to edit environment.rb to require 'myboot' instead which does some setup then requires 'boot' itself."

• No, it should be *BEFORE* Rails::GemBoot#load_rails_gem. environment.rb is not evaluated until the Rails gems and RAILS_GEM_VERSION are already determined and Initializer.run is already underway.

Thx again! -- Chad

Oh, I just realized I was wrong about this:

1. Re: "The simplest path for your existing users is to edit environment.rb to require 'myboot' instead which does some setup then requires 'boot' itself."

You are correct, I could have users edit environment.rb. This is a simpler solution, but still requires environment file hacking. The preinitializers directory approach would allow an auto-install script to install a hook without requiring the user to modify their environment file. It is a viable workaround, though.

Wait - I take that back. I don't think putting a hook in environment.rb before the require of boot.rb will work.

Look at the server script:

#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../config/boot'
require 'commands/server'

The first thing it does is load boot.rb, not environment.rb. So, the preinit hook has to be in boot. I'm betting mongrel works the same way. Or am I missing something?

copying comment from mailing list:

On 10/25/07, Michael Koziarski <michael@koziarski.com> wrote:

I would love to see this patch (or a similar one) make it in, as we are dealing with this very issue with a tool we built test our apps and plugins against multiple versions of Rails in our CI environment. We went with the rubygem approach because it lets use gems for version management, but we are hitting issues in apps due to the way the boot process works.

What are the other issues that you've hit? If it's just about choosing a different version of rails, then can't you just set RAILS_GEM_VERSION in environment.rb? I still don't buy the need for a pre-initializers rig, but perhaps there's a simpler option hiding somewhere.

Nope, this doesn't work. boot.rb and initilization always hits before environment.rb is interpreted, which means any code in environment.rb is too late to have control over the rails version. See my comments on the patch.

By the way, I am working with this approach and the latest boot.rb code in my projects today, and it's working great. All I have to do is set the RAILS_GEM_VERSION environment variable, and that automatically loads the correct rails gem version.

I also have this hooked into cruisecontrol.rb, so that it automatically sets the rails version based on the name of my project - e.g.: a project name of myproject_rails_1.2.5.7919 automatically uses that gem for rails. This makes is a no-brainer to test my project under multiple rails versions via CI, and requires no code changes at all - they all use the same subversion url.

Thx, -- Chad

version 3, now with tests.

description of test scenario which is not currently possible without this patch

I don't think I've done a good job of explaining the need for this. I've tried to summarize it in ticket_9943_preinitializer_hook_failing_test_scenario.txt:

Here is the scenario which is not currently possible without a preinitializer hook:

1. I want my app to use the stable gem (e.g. 1.2.5) by default, _even_ if I have a beta gem installed (e.g. 1.2.5.7919) 2. I also want to use RubyGems Advanced Versioning [1] in my RAILS_GEM_VERSION environment variable to use the _latest_ beta gem that I have installed, e.g.: RAILS_GEM_VERSION='>1.2.5' or '~>1.2.5.0' 3. I want this to happen automatically without having to modify my app (no freezing rails or modifying environment.rb), because I want my Continuous Integration system to automatically run my app against multiple rails versions for regression and edge-rails testing by simply setting the RAILS_GEM_VERSION env var prior to the build.

With this patch, I can have complete control over the gem version which is loaded, and what is set in the RAILS_GEM_VERSION constant before the normal boot gem-selection process occurs.

[1] http://www.rubygems.org/read/chapter/16#page76

version 4, no more config/preinitializers dir, but hardcoded to load config/preinitializer.rb if it exists

Hi,

I've rewritten this patch to use the approach that bitsweat proposed "A simple naming convention like config/initializers/preboot.rb is sufficient and feels appropriate."

The only difference is that I look for it in config/preinitializer.rb instead of under initializers, so it doesn't get mixed up and parsed with the initializers. I also chose a name that is consistent with the 'initializers' dir.

So, this patch should not be completely transparent to people who do not use it, completely innocuous, harmless, safe, and politically correct, as well as addressing a real need (to have the ability to override normal boot.rb behavior without editing boot.rb).

Others in the past have mentioned the shortcomings of the current regex-parsing approach of boot.rb, and this patch is a way to allow alternative implementations to be used without changing any of the existing behavior. This is in the spirit of "that's a great idea, but lets see if it holds its own as a plugin" that is often taken with other potential enhancements to core rails.

rails_preinitializer_hook_ticket_9943.version4.diff

Thanks, Chad

Um, correction: "this patch should NOW be completely transparent blah blah..."

Looks good to me.

+1

(In [8159]) Load config/preinitializer.rb, if present, before loading the environment. Closes #9943.