[Rubygems-developers] VENDOR_HOME (Was: Finding where gems are stored)

Eric Hodel drbrain at segment7.net
Thu Nov 1 01:19:33 EDT 2007

On Oct 23, 2007, at 14:21 , Donavan Pantke wrote:
> 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.

If it doesn't that's a bug.

>>>    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. :)

Is this something they couldn't do with rm?

GEM_HOME is the default directory.  If they specify some other path  
specifically, they can shoot themselves in the foot, just like with rm.

>>> 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.

I can't read your mind to know what you want.  Test it out and see if  
it is suitable.

Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

More information about the Rubygems-developers mailing list