[Rubygems-developers] RubyGems Dependency Type

Chad Woolley thewoolleyman at gmail.com
Wed Jan 30 16:16:36 EST 2008

On Jan 30, 2008 11:32 AM, Susan Potter <me at susanpotter.net> wrote:
> I am willing and able (with about 3-5 hours a week to commit to open
> source contributions across the board) to do most of the grunt work
> and submit a patch for RubyGems project to do the capturing of the
> metadata and change the gem CLI behavior depending on accepted
> proposal.


Strange you should bring this up again - just this week I was bringing
up this thread at work.  I know that Eric is in the camp of "install
everything everywhere", but the fact is that many people just are not
comfortable with that.  Especially people who are on call to support
important production servers.  And, the incident with soap4r gem
screwing up Rails simply by being installed proves that wierd,
unexpected, *impossible* things can happen, especially in the magical
world of Ruby.  You simply don't want any chance of that happening -
especially on production.  That's the spirit behind GemInstaller, and
it's ability to print out "rogue" gems.

I also totally agree that, while it is possible to do what you want
with ERB in a geminstaller.yml config file, that's a hack and
'marries' your infrastructure to GemInstaller.  I can't see why you'd
be opposed to that, but I digress ;)

Anyway, I think this sounds like a very reasonable proposal.  Couple
of comments/suggestions, though:

1. Preserving backward compatablity and default behavior for existing
gems/specs/dependencies is of utmost importance.  Functional sanity
check tests which automatically run against existing gems/specs from
rubyforge, and ensure that dependencies are still handled the same,
would be a good regression safety net.

2. What is the -D switch to install short for?  Naming is important -
maybe -T/--type? or -c/--category?  I kind of like category, not too
generic, not an overloaded term.

3. The area that will cause the most contention is probably the
default categories.  You suggested 'runtime', 'test', and 'compile'.
'runtime' and 'test' sound reasonable, but what is compile?  Are these
for platform-specific build dependencies?  What about build-time only
(non-runtime) dependencies for pure-ruby gems?  Maybe 'build' would be
a more generic choice than 'compile'.  Also, what about deploy- or
publish-time dependencies - such as hoe, rubyforge, webgen/webby, etc?
 Are these in the 'build' category as well?

4. What about dependencies that are required for more than one category?

5. What would the new gem .gemspec file format look like?
Specifically, what about dependencies in more than one category?  Do
you propose adding a new optional parameter to
Gem::Specification.add_dependency?  If this accepted a string or an
array, it would handle the multiple-category issue.

Again, looks good.  If you can make it work, it will be great.

-- Chad

More information about the Rubygems-developers mailing list