On Mon, Jan 13, 2014 at 5:32 PM, Paul Gideon Dann <pdgiddie@gmail.com>wrote:
On Monday 13 Jan 2014 16:35:16 Maxime Gauduin wrote:
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.
That is not a feeling, gemrc is removed on purpose so that you _don't_ run "sudo gem". Your whole system is managed by pacman except for some dirs, why wreak havok in it by using some other package manager? I'm exagerating on purpose, I know rubygem does its job well and there shouldn't be conflicts bewteen the two, but it just doesn't feel right.
We're talking about two completely different domains that both happen to use the filesystem for storage. Ruby gems are not packages in the same sense that Firefox is a package. It's a different concept, and although I agree that Pacman could do an acceptable job of managing Ruby gems insofar as both systems bundle files for installation, it is not possible to map the two systems completely. They are built for different purposes, and have different semantics.
Agreed.
Yes, gem is easy to use, so is pacman. You can achieve the same results with pacman-handled ruby packages given some effort on the maintainer's part (apart maybe for the, imho unneeded, complexity of having multiple versions of the same gem, but that is another story).
To some extent, yes. You end up with a lowest-common-denominator situation. It's acceptable for casual use, I'm sure.
Yep, and that is sufficient for a lot of people. Developers are better off using rubygem/bundler/rbenv, I agree too.
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.
As I mentioned above, you can easily reverse that statement. Why throw Bundler and Rubygems in the mix when you have pacman? I personally think that having pacman-managed dirs tinkered with by another package manager is heresy :P I have no problem using one in "~" or any other dir that pacman does not manage though, and as Rashif said, all in all it's just a matter of options and preferences.
Based on that paragraph, I'd be surprised if you had undertaken any serious development in Ruby. Many Rails developers work on Macs (not to mention other flavours of Linux), and Rubygems and Bundler are cross-platform tools. Relying on Pacman for Ruby development would render a project pointlessly platform-dependent.
I have indeed never undertaken development in ruby, and as I said before, I only use a few ruby packages. However, you said it yourself, ruby and pacman both have different uses, my point was: do not change the content of a dir managed by pacman, do so elsewhere. I'm not saying you shouldn't ever use both. In the end, we're free to do anything we want, I just think it is bad practice to mix things up like described above. In extreme cases, just have a look at Windows, where anybody can install anything anywhere, we all know what it ends up like :P
Paul
Cheers, -- Maxime