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 _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
