Easily build Portfiles from ruby gems

[Paul Guyot]

Jean-Pierre,

MacPorts is based on several axioms. One of them is that it's based  
on a tree of its own, by default /opt/local, and it's here to managed  
everything in this tree.

If you install MacPorts on /usr/local and then install stuff the  
regular way or if you install gems with rubygems, then you're  
violating this axiom. This means several things, among others:
- your tree is in an unsupported state. Don't come and whine if ports  
don't compile.
- you cannot take advantage of MacPorts to uninstall software. I know  
you can do it with gems, but it's not the case with stuff usually  
installed in /usr/local.
- you cannot take advantage of commands such as port provides or port  
livecheck.

Another (more recent) axiom is that MacPorts should depend as much as  
possible on MacPorts stuff only. So say you want a software that is  
not available via rubygems but that depends on a ruby package also  
available through rubygems. If you installed the dependency with  
rubygems and then you try to install the software with MacPorts,  
you're likely to end up with two copies of the dependency on your  
system, the one from RubyGems and the one for MacPorts. Even worse,  
if the MacPorts copy is gem based, it will simply fail to install.  
You've been warned.

Yes, MacPorts should handle foreign files, but definitely not the  
crap you might install there with "make install". I think the way to  
go is an integration à la FreeBSD with CPAN. Yes, MacPorts and  
rubygems should be better integrated and the script is explicitly  
done for this purpose, even if it's just a first step (well, a third  
step, rather).

I realize installing with rubygems has some advantages over MacPorts.  
But installing with MacPorts also has some advantages that long-term  
MacPorts users are aware of. For example, if a gem requires a native  
library, will rubygems install it? Does rubygems provides some  
checksumming facility? Mirroring?

So I think the good policy is:
- install anything you can with Macports
- if it's not available, use rubygems
- once 1.3.3 is out and if you're a MacPorts developer, instead of  
using rubygems, please build a portfile for what you want, test it  
and commit it.

This is just what I *suggest*. Fortunately, I don't administrate all  
the boxes of MacPorts users.

Paul

Le 7 nov. 06 à 08:15, jeanpierre at gmail.com a écrit :

> On 11/6/06, Paul Guyot <pguyot at kallisys.net> wrote:
>
>> With such a script, there's no reason to continue to use gem to
>> install ruby gems.
>
> rubygems allows multiple version of a single package to be installed
> simultaneously and allows one to define a required package version:
> 	require_gem 'hpricot', '>= 0.4.59'
>
> 'no reason' might be a bit strong =)
>
>> Using gem may yield in inconsistencies.
>
> what inconsistencies may arise?
>
>> I know that most ruby tutorial around say: get ruby with
>> darwinports, then use gem. But I strongly disagree.
>
> you have said this before, but i never caught why…
>
>> At some point, we may rename gem binary and put a fake one that
>> displays a warning message.
>
> is that really desirable?
>
> what problem is your script working to solve? it has been suggested
> that the omniscience of macports would be compromised when rubygems
> (or pear, cpan, or how about touch, cp, mv), is that it? why couldn't
> macports become more tolerant and able to handle foreign files? if my
> macports prefix was /usr/local would it be reasonable for macports to
> break just because i installed something by hand into the same prefix?
>
> i think my mirror world, constant lagging and unnecessarily fragile
> comments from august may still apply:
> 	http://article.gmane.org/gmane.os.opendarwin.darwinports/18853
>
> i think it is great that there is a way to convert gems to ports and
> have them available to the macports audience, but i do not understand
> the motivation to discourage the use of and try and replicate some of
> the functionality of rubygems.
>
> cheers,
> jean-pierre

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