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