Ruby ports and 1.9

[Caspar Florian Ebeling]

>>> I have other issues myself. It is not entirely convincing to install
>>> ruby libraries
>>> via a generic package manager like mp, given that ruby has it's own in
>>> the
>>> form of Rubygems, which even comes builtin with 1.9.
>>
>> The same thing applies to Perl. There is CPAN which distributes nearly
>> every Perl module available. But the problem is that you can't declare a
>> dependency on a specific module without a port.
>
> The problem goes both ways, though; you can't install a gem with
> dependencies unless you also install that gem!

if you have a port which has install type gem, then mp is only a frontend
above gem and uses it, putting it's own dependencies mechanism
in place instead. So if you install gems via mp and then add a gem
directly, gem will see this and use it as a dependency. So what you
say is not quite correct, I think.

>
> I realize that this is true for CPAN as well; however, RubyGems is more
> "socially integrated" into the Ruby world, even if it wasn't an official
> part of Ruby until 1.9.  I'd venture that the vast majority of Ruby users
> install RubyGems directly after installing Ruby.

Agreed, everybody will have it. But it never worked that great for me for
things slightly off the beaten rails track. And there have always been
voices critizising rubygems, favoring setup.rb and install.rb.

>
> Except for Rails plugins (which couldn't be gems themselves until recently,
> but which still required RubyGems to be installed), I haven't seen anything
> distributed as other than a gem in the past few years.

This is not my experience. I think it is true for the vast majority of
things in the
rails ecosystem, but older libraries are rarely gems. One example I
ecountered lately is ruby-mmap. This one esoteric, but there are plenty of
other examples I guess.

>
> To me, in the Ruby world, the right way to install a gem is to use "gem
> install".  That whole infrastructure shouldn't be duplicated in the MacPorts
> world, any more than you'd create a port for each Firefox extension.

Admitted. Only mp does not duplicate rubygems, but rather layers over
it, installing packages as gems if the port maintainer wants. It does
duplicate the
indexes of rubygems, which are a weak point of it anyway (slowness!).
I don't know how
much this has been improved with 1.2.0 now. But I just tried to install mysql
with gem1.9 and it still fetchs mysql2.7, even though 2.8pre-something is the
one which is compatible with ruby1.9.

This could be smoothed over by mp, and all we have to do is to decide not to
drop support for ruby ports with ruby1.9. To provide for that is what my
patch is for.

> So to me, the question is: Are there actually ports that depend on gems, but
> aren't gems themselves?  If so, how hard would it be to create a fake
> "gem-dependency" port, which will get auto-installed as a dependency by
> those ports, and which will in turn "succeed" by verifying that the given
> gem is installed?

I think a port would be nice for any ruby library or program which does not
come as a gem, or for which the author is not much bothered to keep
the gem index current.

>> Also, in my opinion it's easier for users to use only one package manager
>> (like MacPorts) to install software. Using cpan, gem and others additionally
>> might not be that easy. Especially this comes true when using a GUI.
>
> If you're using Ruby, you're at the command line at some point to run your
> code

I don't think this is necessarily true. Especially now that there is quite some
thinking about improving gui toolkits in the ruby community. And once they
get more mainstream some nice broad-audience tool might come out of it.

Actually I think we should not drop support for ruby1.9 ports (that's
why I wrote the
patch after all).



Florian




-- 
Florian Ebeling
florian.ebeling at gmail.com