Le 7 nov. 06 à 01:00, James Berry a écrit :
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.
I'm not sure I understand what you mean by the "usual" location. /opt/local/bin/gem installs stuff in /opt/local /opt/local/bin/port also does, when it uses gem and when it doesn't. Technically, the only difference when using a port based on the new script and gem is that with a port: - you can deactivate the port. - the files are registered in MacPorts database (filemap). Otherwise, the files are at the same place. Paul -- Ministre ultraplénipotentiaire en disponibilité. Mobile. Sans baignoire fixe. http://www.kallisys.com/ http://www-poleia.lip6.fr/~guyot/