[arch-general] [arch-dev-public] Ruby directory clean up proposal.

Peter Lewis plewis at aur.archlinux.org
Mon Feb 13 20:53:01 EST 2012


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 

> 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 

> I'm currently leaning towards 1 since it will be a simple solution
> with no changes needed to existing ruby-* packages.


Of course, suggesting RVM for user-installed gems(ets) is probably also a good 


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:


It's hacky, but it works :-) I wish there was a cleaner way.

More information about the arch-general mailing list