[arch-general] [arch-dev-public] Ruby directory clean up proposal.
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
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
> 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
> 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