Multiple vendor/gem paths

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.

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.

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 can get my code at:

Its just a single commit based off the 2-3-stable branch. See: http://github.com/dreamcat4/rails/commit/0b347ba81210363035d998831b66564b42adf006

dreamcat4 dreamcat4@gmail.com

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

loaded. It's a tricky issue that Merb has solved by using a different mechanism to configure gems.

Yes could well be worthy of some evaluation.

You might also want to take a look at #1721 on Lighthouse; it's sort of a centralized discussion ticket for this issue.

Thanks, i'll head over there right now.

dreamcat4 dreamcat4@gmail.com