On Mon, Jan 13, 2014 at 5:32 PM, Paul Gideon Dann <pdgiddie@xxxxxxxxx>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
