Easily build Portfiles from ruby gems

John Labovitz johnl at johnlabovitz.com
Mon Nov 6 08:39:24 PST 2006

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.)

In the meantime, I'll be standing up for voice of the common gem. ;)


More information about the macports-dev mailing list