Opened 15 years ago

Closed 14 years ago

Last modified 11 years ago

#6963 closed enhancement (fixed)

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

Reported by: rcavanaugh@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 1.0
Keywords: Cc: pguyot (Paul Guyot)

Description (last modified by jmpp@…)

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

Attachments (1)

ruby-1.0.tcl.patch (2.2 KB) - added by rcavanaugh@… 15 years ago.
ATTACHMENT: patch implementing rubygems support for ruby.setup

Download all attachments as: .zip

Change History (17)

Changed 15 years ago by rcavanaugh@…

Attachment: ruby-1.0.tcl.patch added

ATTACHMENT: patch implementing rubygems support for ruby.setup

comment:1 Changed 15 years ago by rcavanaugh@…

blocked: 6965

comment:2 Changed 15 years ago by rcavanaugh@…

blocked: 6966

comment:3 Changed 15 years ago by rcavanaugh@…

blocked: 6967

comment:4 Changed 15 years ago by rcavanaugh@…

blocked: 6968

comment:5 Changed 15 years ago by rcavanaugh@…

blocked: 6969

comment:6 Changed 15 years ago by rcavanaugh@…

blocked: 6970

comment:7 Changed 15 years ago by rcavanaugh@…

blocked: 6971

comment:8 Changed 15 years ago by jberry@…


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.



comment:9 Changed 15 years ago by rcavanaugh@…


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'".


comment:10 Changed 15 years ago by jberry@…


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... ;)


comment:11 Changed 15 years ago by rcavanaugh@…


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.

comment:12 Changed 15 years ago by pguyot (Paul Guyot)

Cc: pguyot@… added
Status: newassigned

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.

comment:13 Changed 15 years ago by 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...

comment:14 Changed 14 years ago by pguyot (Paul Guyot)

Resolution: fixed
Status: assignedclosed

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.

comment:15 Changed 13 years ago by jmpp@…

Description: modified (diff)
Milestone: MacPorts base enhancements

comment:16 Changed 11 years ago by jmroot (Joshua Root)

Milestone: MacPorts Future
Note: See TracTickets for help on using tickets.