Hi, I'm not a dev, so am replying on arch-general, but a TU who uses a lot of ruby on Arch. Thanks for thinking about this. I too have been trying to come up with my own sane way of using ruby - gems particularly - with Arch. On Sunday 12 Feb 2012 17:37:17 Thomas Dziedzic wrote: > Current layout: > /usr/lib/ruby/site_ruby - packages either installed here > /usr/lib/ruby/gems/[ruby_base_version] - or here, this directory > contains both pacman installed packages and packages installed using > the gem tool. > > Planned layout: > /usr/lib/ruby/site_ruby - manually installed files by user go here, > packages shouldn't touch this > /usr/lib/ruby/gems/[ruby_base_version] - pacman packages built from gems go > here /usr/lib/ruby/vendor_ruby - ruby packages installed with pacman which > aren't gems go here > $HOME/.gem/ruby/[ruby_base_version] - used by the gem command to > install packages unmanaged by pacman +1 from me, except that we should probably emphasise that /usr/lib/ruby/site_ruby really is for site-specific stuff. Anything that is generic enough to be able to go in a pacman package (and/or a gem) should do. > /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? > If the user chooses to install gems using gem, they will have to add > the bin directory to the $PATH: > export PATH="$PATH:$(ruby -rubygems -e 'puts Gem.user_dir')/bin". Yep, or just something derived from $GEM_HOME if we were to use that approach instead. > Benefits of this change include: > Using the proper directory layout introduced in ruby 1.9 (using > vendor_ruby). Clean separation of pacman installed packages > (/usr/lib/ruby/gems/[ruby_base_version] & /usr/lib/ruby/vendor_ruby) > from gem installed packages ($HOME/.gem/ruby/[ruby_base_version]). > > Problems left: > The user will still be able to install to the system wide gem > directory /usr/lib/ruby/gems/[ruby_base_version] if they remove > --user-install from /etc/gemrc > > Possible remedies: > 1) Leave it as is. > If the user runs gem with --no-user-install then gem will still > install the files to the system wide directory at > /usr/lib/ruby/gems/[ruby_base_version] and will install binaries to > /usr/bin > This should provide a clean default and is the easiest path. > This option is still better than the one we currently use where we > try to install to the system wide location by default. I think it's worth separating out the "user" and the "admin" in this argument. To install a gem system-wide, you have to do something like "sudo gem install XXX", right? This is almost always a bad idea, IMO, and people hopefully won't do it at least during the normal run of working with ruby. Personally, I don't let gem mess with anything outside my home directory. And plain "gem install XXX" will not accidentally install system-wide, right? Ruby is quite good for separating between development and deployment environments - it seems to make sense for us to do a similar thing here, seeing the Arch OS layer itself as a particular kind of deployment, where things are managed by pacman. > 2) Change all ruby pacman packages to use local > _gemdir='/usr/lib/ruby/vendor_ruby' > This would free up /usr/lib/ruby/gems/[ruby_base_version] which we > could move to /var/lib/ruby/gems/[ruby_base_version] for system wide > gems installed with the gem command. 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. > I'm currently leaning towards 1 since it will be a simple solution > with no changes needed to existing ruby-* packages. Yep. Of course, suggesting RVM for user-installed gems(ets) is probably also a good idea. Pete. 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.
