On Tue, Feb 14, 2012 at 3:04 AM, Peter Lewis <ple...@aur.archlinux.org> wrote: > On Monday 13 Feb 2012 20:47:01 Thomas Dziedzic wrote: >> >> /etc/gemrc - contains "gem: --user-install" to install user installed >> >> gems with gem to $HOME/.gem/gems >> > >> > I didn't know about --user-install, but I just set GEM_HOME (actually, I >> > use RVM). Can what you want be done by globally setting GEM_HOME to be >> > based off of $HOME? Or is --user-install the preferred way? >> >> I did look into $GEM_HOME but I thought this was inadequate since >> running sudo gem install foo would still install foo to the >> system-wide gem directory. Having --user-install in /etc/gemrc forces >> it to install to /root/.gem/gems instead. > > Great, I should have read up on --user-install then. Sounds great. > > >> > And as much as I have to admit that I'd really like to be able to install >> > gems system-wide and use their built-in dependency management, bundler >> > etc... I think that road probably leads to madness and death, especially >> > when many popular gems will still be managed by pacman (and rightly so). >> > So, I would be careful about doing this, and would suggest that we go for >> > only letting 'gem' install things under $HOME. Anything that should go >> > system-wide should have a PKGBUILD. >> >> Right, by default I want it so that you wont be able to install system >> wide gems with gem. >> But I can't stop users removing --user-install from the gemrc file and >> installing to the system-wide directories. > > Perhaps we have an argument for proposing an option like --user-install that > doesn't allow users to disable it then. >
I think just making --user-install the default will be fine. I don't want to stop people from doing this completely since there will always be around it. > >> I have another plan brewing in regard to letting users separately >> install pacman installed gems and gem installed gems to the >> system-wide directory. >> I wont do it in this cleanup iteration, but next cleanup, I will add a >> /var/lib/gems or /var/lib/ruby/gems folder specifically so that when >> running sudo gem install without --user-install, it will install to >> /var/lib/.. and gems installed via pacman will install to >> /usr/lib/ruby/gems. This will cleanly seperate pacman installed ruby >> gems to /usr and sudo-gem without --user-install installed gems to >> /var. This will bring ruby and rubygems into fhs compliance, at least >> afaik :) > > Nice. Just out of interest, what RUBYLIB order precedence would you use, to > deal with the case when some similar things (say different versions of the > same gem) were installed in /usr/lib/ruby and /var/lib/gems at the same time? > The order will be $HOME/.gem/ruby, /var/lib/gems, /usr/lib/ruby/gems Just to reiterate, the var path will be for system wide gems installed with gem. The usr path will be for gems installed with a PKGBUILD. Upstream seems to be fine with this order also. > >> Doing this will require modifying the GEM_PATH and all PKGBUILDs that >> install ruby gems. This wont break the PKGBUILDs just make them >> uncompliant with our standards, instead it will just install to /var >> if you don't change them which will be in GEM_PATH. BTW, GEM_PATH is >> the location where rubygems searchs for gems. >> >> I have already talked with upstream rubygems devs and they seem to >> agree that this is a good plan :) > >> I'm certain I will go with 1 this cleanup and will implement the above >> on the next cleanup. > > All great. > > >> > Of course, suggesting RVM for user-installed gems(ets) is probably also a >> > good idea. >> >> For rails development, I can't recommend rvm enough, you can manage >> multiple gemsets with multiple ruby versions, and have it >> automatically load project specific .rvmrc files when you cd into >> those directories. >> This is probably one of the nicest language management tools for a >> programming language I have encountered so I would recommend it :) > >> Ofc, rvm might be overkill if you're just doing development on small >> projects, or if you just don't need a clean separation of multiple >> ruby environments. > > Agreed. It really is a breeze to use. I don't do much rails, but just use > clean gemsets along with bundler, most of the time. It helps with predicting > what's going to happen when I want to run the code on another machine. > > > >> > PS. A while ago I was getting very frustrated that the version of rubygems >> > bundled with ruby itself was so out-of-date so quickly, but 'gem update >> > --system' is a very bad idea in combination with pacman. So, I spent a >> > while hacking together this package, which installs the latest version of >> > rubygems itself alongside ruby, system-wide: >> > >> > https://aur.archlinux.org/packages.php?ID=50346 >> > >> > It's hacky, but it works :-) I wish there was a cleaner way. >> >> I was also thinking about this, and I might split rubygems off into a >> seperate package and have ruby optdepend or depend on it so I can >> update the package separately from ruby. > > Hell yeah. Please do. I assume you're aware of this: > > https://bugs.archlinux.org/task/17611 > I wasn't aware of this bug report, but I was aware of the recently added configure flag: --disable-rubygems disable rubygems by default > Pete.
