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 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? > 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 Pete.
