Hey Paul,
On Nov 6, 2006, at 6:40 AM, Paul Guyot wrote:
In both cases, it creates a new directory, rb-gem_name, with the
Portfile in it. Please note that this portfile uses the new
rubyforge_gem fetch syntax (available with the ruby group
modification I just committed to the svn repository). The second
version will download the gem in the current directory. I need the
file to be able to compute the checksums. Besides, if several gems
exist and some of them are binaries, it will ask you to choose a
version (using the native gem mechanism).
Looks great! I think this is a good step forward. The gem issues were
getting a bit weird. This will help MacPorts really shine as a source
for ruby software.
This script requires gems (sudo port install rb-rubygems).
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.
Question: does it make sense to now make the gem software installed
by MacPorts actually install gems into the "usual" location rather
that in /opt/local? That would mean that MacPorts can source gem, but
gem installs gems in a typical fashion, not intermingling them into /
opt/local, which I think would complete the separation.
Thanks for your work on this!
James
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
