Easily build Portfiles from ruby gems
Hi all, I wrote a script that generates a ready to use Portfile for any gem. You can find it here: http://www.opendarwin.org/~pguyot/gems_to_portfile.rb The syntax is pretty simple: ./gems_to_portfile.rb gem_file.gem or ./gems_to_portfile.rb gem_name 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). 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. Enjoy! Paul -- Ministre ultraplénipotentiaire en disponibilité. Mobile. Sans baignoire fixe. http://www.kallisys.com/ http://www-poleia.lip6.fr/~guyot/
Salut Paul, Would you mind explaining this a little more? It is not clear to me why (as a developer just starting to use Ruby) I would want to get my libraries from MacPorts instead directly from rubyforge or another gem server. In a similar vein, should MacPorts replace CPAN (Perl) or PEAR (PHP)? I'm replying on-list, as I suspect others have the same question. But feel free to respond privately if this falls outside the scope of the macports list. Merci, -Mark On 11/6/06, Paul Guyot <pguyot@kallisys.net> wrote:
Hi all,
I wrote a script that generates a ready to use Portfile for any gem. You can find it here: http://www.opendarwin.org/~pguyot/gems_to_portfile.rb
The syntax is pretty simple:
./gems_to_portfile.rb gem_file.gem
or
./gems_to_portfile.rb gem_name
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).
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.
Enjoy!
Paul -- Ministre ultraplénipotentiaire en disponibilité. Mobile. Sans baignoire fixe. http://www.kallisys.com/ http://www-poleia.lip6.fr/~guyot/
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
On Nov 6, 2006, at 9:55 AM, Mark Fredrickson wrote:
Would you mind explaining this a little more? It is not clear to me why (as a developer just starting to use Ruby) I would want to get my libraries from MacPorts instead directly from rubyforge or another gem server. In a similar vein, should MacPorts replace CPAN (Perl) or PEAR (PHP)?
It gives you one system for controlling (and updating) added software on your machine. It also helps keep everything in ${prefix} (/opt/local) under MacPorts control. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
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
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.) In the meantime, I'll be standing up for voice of the common gem. ;) --John
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/
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/
On 11/6/06, Paul Guyot <pguyot@kallisys.net> 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
Jean-Pierre, MacPorts is based on several axioms. One of them is that it's based on a tree of its own, by default /opt/local, and it's here to managed everything in this tree. If you install MacPorts on /usr/local and then install stuff the regular way or if you install gems with rubygems, then you're violating this axiom. This means several things, among others: - your tree is in an unsupported state. Don't come and whine if ports don't compile. - you cannot take advantage of MacPorts to uninstall software. I know you can do it with gems, but it's not the case with stuff usually installed in /usr/local. - you cannot take advantage of commands such as port provides or port livecheck. Another (more recent) axiom is that MacPorts should depend as much as possible on MacPorts stuff only. So say you want a software that is not available via rubygems but that depends on a ruby package also available through rubygems. If you installed the dependency with rubygems and then you try to install the software with MacPorts, you're likely to end up with two copies of the dependency on your system, the one from RubyGems and the one for MacPorts. Even worse, if the MacPorts copy is gem based, it will simply fail to install. You've been warned. Yes, MacPorts should handle foreign files, but definitely not the crap you might install there with "make install". I think the way to go is an integration à la FreeBSD with CPAN. Yes, MacPorts and rubygems should be better integrated and the script is explicitly done for this purpose, even if it's just a first step (well, a third step, rather). I realize installing with rubygems has some advantages over MacPorts. But installing with MacPorts also has some advantages that long-term MacPorts users are aware of. For example, if a gem requires a native library, will rubygems install it? Does rubygems provides some checksumming facility? Mirroring? So I think the good policy is: - install anything you can with Macports - if it's not available, use rubygems - once 1.3.3 is out and if you're a MacPorts developer, instead of using rubygems, please build a portfile for what you want, test it and commit it. This is just what I *suggest*. Fortunately, I don't administrate all the boxes of MacPorts users. Paul Le 7 nov. 06 à 08:15, jeanpierre@gmail.com a écrit :
On 11/6/06, Paul Guyot <pguyot@kallisys.net> 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
-- Ministre ultraplénipotentiaire en disponibilité. Mobile. Sans baignoire fixe. http://www.kallisys.com/ http://www-poleia.lip6.fr/~guyot/
participants (6)
-
Daniel J. Luke
-
James Berry
-
jeanpierre＠gmail.com
-
John Labovitz
-
Mark Fredrickson
-
Paul Guyot