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