On Monday 22 October 2007 11:44:52 am Eric Hodel wrote: > On Oct 22, 2007, at 03:42 , Marcus Rueckert wrote: > > On 2007-10-21 20:39:05 -0700, Eric Hodel wrote: > >> What you propose sounds no different than setting GEM_PATH > >> appropriately. > > > > 1. could you give an example how it could look like? > > > > how would you install gems into the vendor dir so the user can find > > them? > > gem install -i /path/to/vendor/gems > > echo export GEM_PATH=/path/to/vendor/gems:/path/to/gem/home >> /etc/ > profile
Perhaps. I don't have a full workstation up, does a gem list -l list all gems in GEM_PATH? The idea here is to make the vendor are as seemless to the end user as possible. > > > how can you get gem to treat the vendor dir as read only unless > > passed a --vendor option (just an example) with the GEM_PATH > > solution? > > The regular permissions system handles this just fine: > > sudo gem install -i /path/to/vendor/gems I'm not keen on letting the permission system handle this, since there are definitely cases I can think of where a user might sudo a gem command and still mess up the vendor area. However, the GEM_PATH solution may still work. Is it possible for us to say that any modifications to gems MUST be done inside GEM_HOME? That is, no deletes or additions could be made to other directories in GEM_PATH, only in GEM_HOME. Pardon me if the code works this way already, as I said I'm not where I could test it myself right now. :) > > > 2. using the environment variable has the disadvantage that the > > user can > > break it. while an additional path hardcoded in the config of gem > > cant be lost that easily. > > Is PATH immune from this problem? No, but a better analogy would be setting LD_LIBRARY_PATH. And on most systems, we try to avoid doing that as best as possible. Same should be with Gems. So, I'm thinking that judicious use of GEM_PATH may be a good solution here, we just want to try and get that behavior the way we would like it. Thanks! Donavan > > -- > Poor workers blame their tools. Good workers build better tools. The > best workers get their tools to do the work for them. -- Syndicate Wars > > > _______________________________________________ > Rubygems-developers mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rubygems-developers _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
