On Mon, Jan 13, 2014 at 12:33:30PM +0000, Paul Gideon Dann wrote:
On Monday 13 Jan 2014 12:59:28 Maxime Gauduin wrote:
IMHO, the reason why you would choose to use rubygem over pacman depends of how extensive a ruby user you are. I like to have gems handled by pacman, but I only use a few of them and don't need to have several versions of the same gem. Having them installed system-wise also makes them easily available to all users. That being said, you can achieve the same with rubygem by sharing a common ruby home between your users. As for the files not handled by pacman, home dirs are not referenced anyway so having gems in it really doesn't hurt.
For system-wide gems, I do "sudo gem install <gem>". That works because I've restored /etc/gemrc so that it reads simply "gem:", instead of "gem: --user-install". I'm still not clear on why this configuration file is altered in the Arch package. I think it's because there's a feeling that system-wide gems should be handled by pacman, which I personally find weird.
I get that people may be afraid of using a second package manager, but Rubygems is incredibly easy to use, and handles gems much more effectively than can be achieved in pacman, because Rubygems is domain-specific. A quick command reference on the Ruby page on the Wiki should be enough.
When you start doing Ruby development, you quickly come to rely on Bundler, which relies on Rubygems. Throwing Pacman into the mix would cause a big mess, at least until you learn to use rbenv or something similar.
Paul
There are 6 ruby gems I use regularly: - Jekyll - Kramdown, a Ruby markdown parser (which I use with Jekyll) - Nanoc - Middleman - Heroku - Haml - Sass Several of these gems have other Ruby dependencies, some of which are shared; however, some gems (in my case Jekyll and Middleman) depend on different versions of the same gems. rubygems is able to handle installation, upgrades and removal of multiple versions of the gems simultaneously; however, some time back I tried to use pacgem[1] to allow pacman to handle packaging and updates in a uniform manner, since it seemed more "Arch-like." That was how I discovered the multi-version dependencies: As pacman will only allow a single version of a package to be installed on the system at a given time, I was frequently alerted to "updates" of dependency gems I had installed. Middleman depends on a later version of a particular library than does Jekyll; if I update the gem via pacgem, Middleman will function, while Jekyll will break. It simply wasn't possible to use both simultaneously, and since I depend on Jekyll for work I do, that's unacceptable. It's far simpler (in my opinion) to use "gem install" as $USER to install to my /home directory and add the installation directory to $PATH, as I'm the only one who uses my machine. In the event that gems do (for whatever horrific reason) become unmanageable, one can simply nuke the directory where they're installed and reinstall all necessary gems rather quickly, without risk to the system at large. As a side note, since gems are by default distributed through the Ruby gems network, including them in the AUR essentially amounts to writing a PKGBUILD that serves as a wrapper to rubygems anyway. [1]: https://aur.archlinux.org/packages/pacgem/