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/