On 11/6/06, Paul Guyot <[EMAIL PROTECTED]> 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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
