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.