RFE: rubygems support for ruby.setup in group/ruby-1.0.tcl

[rcavanaugh@…]

This enhancement allows for installing ruby libraries via the rubygems system. It builds on the existing ruby.setup functionality and allows for the following in portfiles:

ruby.setup rails 1.0.0 gem {} rubyforge:7653

[rcavanaugh@…]

ATTACHMENT: patch implementing rubygems support for ruby.setup

[jberry@…]

Rich,

I thought about doing this too. I'm concerned though, about the following:

(1) We wouldn't be able to use such support until we roll darwinports to 1.3, as the group code wouldn't be available to ports.

(2) I'm worried that by relying on gem, we're not really in control anymore of what we've installed, how to uninstall it, etc. In other words, gem is a package system in it's own right, and will resolve it's own dependencies. If we call it, we have no idea what it's going to do. It seems like the user has got to decide: (a) either install ruby ports with dp, or (b) install ruby software with gems. But I'm not convinced that dp should try to install ruby software through gems.

Feedback?

James.

[rcavanaugh@…]

James,

I thought of the package system issue too when I was creating this. I decided however, as a user, I would strongly prefer to only interact with one package system.

I looked into how rubygems works prior to creating this. It doesn't maintain any database. It simply looks at what is installed in the gems directory. In this way rubygems installed software ends up not being significantly different than other packages installed by dp.

It's also worth noting, the actual install is handled by dp. This patch has rubygems do it's install into the staging area. The uninstall is handled entirely by dp and because rubygems doesn't maintain a central database, it all works.

The primary driver for me creating this patch was running across ruby packages that expected the gems of certain packages to be installed. For example, they did "require_gem 'activerecord'" instead of "require 'activerecord'".

Thoughts?

[jberry@…]

Rich,

Interesting question. But let's look at a potential:

pkg a installs gem ag that requires gem gd. These are both installed as part of package a. pkg b installs gem bg that also requires gem gd. The requirement for gem gd is already fullfilled by a so it is not re-installed? pkg a is now removed. With it goes gem gd. Pkg b then breaks, because it had an implicit and unexpressed dependence on gem bg.

I don't know. I'm still not there. It still seems like if you need a gem you should install it though gems. Unless a dp port is almost "virtual" and ends triggering a gem install almost as a side-effect. An intentional side effect? In which case dp port uninstall wouldn't uninstall the gem...

Your continued thoughts are welcome... ;)

James.

[rcavanaugh@…]

James,

As for the potential situation you outlined, I think that's an issue for port maintainers. For example, exactly what you outlined is the case with the various rails ports I submitted.

In that case I looked at the various dependencies of the gems and made sure I had ports for those dependencies and the dependencies defined clearly in the Portfiles. The gem command's dependency installation never kicks in because the port command takes care of it all in the proper order.

The same issue comes up with most ports. The only difference is that the Gnome .tgz alone can't express it's dependency on libxml2 (and a million other things). So it's up to the maintainer of the port to express those dependencies in the Portfile.

Also, the default behavior of the gem command is not to install dependencies automatically. The gem command will prompt for permission to install dependencies if they don't already exist. I don't know how that would interact with the port command but I can't imagine it would be good.

While I do completely agree it could be a problem, it strikes me as nearly identical to the problems port maintainers must deal with as far as dependencies go. This is being said however from the point of view of someone that's very unfamiliar with the policies and history of the Darwinports project in this particular issue.

Overall though, I think what I originally submitted for rails is a good example of how the gem support should be used if it's ever included in dp. I could have simply created a single port called rb-rails that did the equivalent of "gem install rails --include-dependencies". Instead I created ports for all the dependencies and defined those in the rb-rails Portfile.

[pguyot (Paul Guyot)]

I find this patch interesting.

The only improvement I would make would be to specify the full path of gem command line tool (with ${prefix}/gem) in the system call to make sure it's DP version of gem we use.

James, let me take your example: pkg a installs gem a which depends on gem b pkg b installs gem b

If pkg is well designed, pkg a will depend on pkg b. Both the prompt of gem and the -t option should help developers of gem package to respect this.

If you're scared with this, I think we could simply patch gem to prevent it to do any dependency install and end with an error.

[jberry@…]

Hi Paul,

I, unfortunately, haven't had anytime to think about ruby stuff for a while. If you want to take this on and do the right thing with it, I trust you...

[pguyot (Paul Guyot)]

OK. I've committed this with two changes:

• I removed the test for the post-destroot phase. It looks like a workaround for a deeper problem: the gems code didn't create the worksrcdir.

• I hard-coded the path to gem as mentioned in my comment. So we're sure we use DP's gem.

This is a cool addition. Thanks Rich.