[arch-general] Ruby gem packages in Arch

[Maxime Gauduin]

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