[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