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

[Donavan Pantke]

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
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers