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

Donavan Pantke avatar at spellboundnet.com
Thu Nov 1 18:21:23 EDT 2007


On Thursday 01 November 2007 01:19:33 am Eric Hodel wrote:
> 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.
>

The gem path solution works well. I've added a couple of patches to the 
tracker that will warn users about uninstalling stuff outside of GEM_HOME and 
help repackagers redefine the stock locations if they need to and consider 
using the environment overrides to not be reliable enough.

Thanks!
Donavan



More information about the Rubygems-developers mailing list