On Jan 30, 2008 11:32 AM, Susan Potter <[EMAIL PROTECTED]> 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.
Susan, 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. Thanks, -- Chad _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
