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