On Jun 11, 2009, at 5:56 AM, dreamcat four wrote:
>
> Hi !
>
> Trying to write a patch which will allow the user to configure where
> to have their vendor/gems directory (ies!). However this is rather
> tricky to add because there seems to be 3 main times when rails will
> want to load up and work with vendor/gems.
>
> 1) the Rake tasks to freeze / unfreeze gems
> 2) the Rails startup code in the very beginning, will try to load
> once the gems
> 3) the time after environment.rb and *after* the config,gem in run
> initializer do |config|.
>
> So far I have succeeded in doing muliple paths for 3), but not 1)
> and 2).
> I can put in my environment.rb a configuration line like this:
>
> config.gem_paths = ["#{PLUGIN_PATH}/vendor/gems"]
>
> But if telling the load paths is happen too late in the environment.rb
> file, then where earlier can we specify such a configuration?
>
> Which is basically an equivalent of config.plugin_paths for plugins
> (which is already in rails). The problem is that these rake tasks and
> early initialization code don''t read the environment.rb file until
> much later on. I think that it would be nice to have this feature, but
> am finding the gems management code a little too complex to be able to
> accomodate this one.
The challenge is that the code in environment.rb may pull in code
loaded from gems (eg, calling ''require'') and therefore
can''t always be
loaded. It''s a tricky issue that Merb has solved by using a different
mechanism to configure gems.
> This is in contrast to rails plugins which don''t need such a
complex
> loading beforehand. Why are the vendor/gems need to be loaded up so
> rigourously? If you have checked out your vendor/gems under version
> control then why the need for these rake tasks ? It seems slightly
> inflexible approach.
Gems need to be treated with more care because they''re more
complicated - plugins typically don''t have native components, for
instance. Some gems also may need to be loaded before Rails is fully
loaded; for example, when using an unbundled copy of tzinfo.
> And were there any other plans to re-think the gem code (ie at times
> like during search of gem dependancies at startup, etc) ?
> Thoughts and comments appreciated.
You might also want to take a look at #1721 on Lighthouse; it''s sort
of a centralized discussion ticket for this issue.
--Matt Jones