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

Marcus Rueckert darix at web.de
Mon Oct 29 22:22:51 EDT 2007


On 2007-10-29 21:11:32 -0400, Donavan Pantke wrote:
> Date: Mon, 29 Oct 2007 21:11:32 -0400
> On Tuesday 23 October 2007 05:21:01 pm 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.
> >
> > > >    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.
> 
> Okay, I think I figured it out. There are 2 patches in the tracker for these: 
> 15150 and 15151. One patch makes it easier for repackagers to specify the 
> hard defaults for paths. It's possible that setup.rb could be extended to 
> produce the defaults, but having a separate defaults.rb will help with either 
> case. The second patch will require a user prompt or --force if the gem 
> resides in somewhere in GEM_PATH but not in GEM_HOME. This should help people 
> to not accidentally remove things that aren't in GEM_HOME. File permissions 
> are the ultimate decider on if someone can uninstall or not, which true with 
> both GEM_HOME and GEM_PATH, and is as it should be.
> 
> Marcus, do you think that this would work well for the opensuse builds of 
> gems?

sounds good!:)

  darix

-- 
           openSUSE - SUSE Linux is my linux
               openSUSE is good for you
                   www.opensuse.org


More information about the Rubygems-developers mailing list