Easily build Portfiles from ruby gems

[Paul Guyot]

Le 7 nov. 06 à 01:39, John Labovitz a écrit :

> On Nov 6, 2006, at 6:40am, Paul Guyot wrote:
>
>> With such a script, there's no reason to continue to use gem to  
>> install ruby gems. Using gem may yield in inconsistencies. I know  
>> that most ruby tutorial around say: get ruby with darwinports,  
>> then use gem. But I strongly disagree. At some point, we may  
>> rename gem binary and put a fake one that displays a warning message.
>
> Please don't.
>
> I've been using native Ruby gems for at least two years with  
> MacPorts, and have had absolutely no trouble.
>
> I don't have any problem with *providing* gem ports, especially for  
> major/complex systems like ImageMagick and Rails.  I use a select  
> few rb-* gems, for their ease of installation (eg, rb- 
> imagemagick).  The combination of native and ported gems has never  
> caused me grief; on the contrary, it's been a very pleasant  
> experience.  (Yes, I realize there could be dependency issues with  
> a gem that required something installed as a port.)
>
> Besides, there are currently over a thousand gems; only ~130 of  
> those currently have ports.  Do you really suggest that we make  
> ports for every single one?  And keep them up to date?
>
> Perhaps if there are specific issues or conflicts, we could talk  
> about those and try to find a solution or a workaround. (For  
> example, I wonder whether a gem port could somehow be a wrapper  
> around the gem command; that way the user would continue to use the  
> ports system, but actually be installing native gems that were kept  
> track of.)

This is exactly what happens for a while now. That's true that only  
12 ports use this technology, but it's there and it works (including  
for rails).

If you look at rb-actionmailer, the ruby.setup line says:
ruby.setup	actionmailer 1.2.3 gem {} rubyforge:11331

It means: use the gem mechanism, get it from rubyforge, the ID is 11331.

However, the trouble with this was to get the ID. I realized that gem  
itself doesn't know about it but download from another URL. So the  
new code (available only in svn now, forthcoming in 1.3.3) works like  
this:
ruby.setup	mongrel 0.3.13.4 gem {} rubyforge_gem

I know that using gem and port at the same time is almost without any  
trouble. Gem is a good piece of code and it's behaving. The only  
issue is that gem is installing stuff in /opt/local and MacPorts  
doesn't know about it.

So from there, I think there are the following paths:
- port the one thousand or something gems to MacPorts using the  
script I wrote. It's just a matter of converting and testing.
- patch gem so it registers the files into MacPorts system.
- something between the two.

It is what FreeBSD does with CPAN as far as I know. CPAN can install  
stuff and what is installed is registered in FreeBSD database. Until  
then, it might be worth it when enough gems are made available  
through MacPorts to just rename gem command so it's still available  
and implement a fake warning one to convince ruby users to use the  
MacPort version or provides tickets so we update to the latest when  
there's a problem.

Paul
-- 
Ministre ultraplénipotentiaire en disponibilité.
Mobile. Sans baignoire fixe.
http://www.kallisys.com/
http://www-poleia.lip6.fr/~guyot/