Chad,
Thanks very much for responding. Your suggestions are great. The
internal gem was tailored to the client development
environment/philosophy, so you made some good points that I either
hadn't thought of before or weren't relevant in our specific client
context.
> 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.
Great point. Internally I just had to make sure internal clients were
satisfied, so I will refer to the tests and code of RubyGems to
appreciate better the current logic. This is a good place for me to
start before changing/adding any code.
> 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.
I have have no problem to change the naming. -D/--dependency-type was
in our internal gem we used as a gem CLI wrapper, but frankly I am
more interested in providing a way to describe this in metadata than
worrying about the CLI argument naming myself and -c/--category
appears like a better fit for a more general setting.
> 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?
I have no problem changing the names of the "categories" at all.
Using 'build' instead of 'compile' sounds like a good idea.
Internally we were trying to be Maven-esque since most internal
Java-gone-Ruby developers at the client used Maven previously (and
apparently loved it), but that is a very small number of real Ruby
developers in the "wild":)
> 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.
Great question and I should have mentioned this in the first post.
Indeed the last argument accepted is an array (the usual Ruby way) and
in our implementation, multiple dependencies were added under the
surface when multiple categories were specified.
>>>> s.add_dependency('rubygems', '>=0.8.0', :build, :test)
which is equivalent to:
>>>> s.add_dependency('rubygems', '>=0.8.0', :build)
>>>> s.add_dependency('rubygems', '>=0.8.0', :test)
However, there might be implications that I haven't thought of
regarding adding this. Internally we haven't been bitten by anything
that we couldn't fix ourselves, but I am always open to learning
historical context that isn't obvious from the codebase or
documentation that may affect the proposal.
Thanks and will start looking at the RubyGems trunk and mature popular
project gemspecs (for bw compat) over the weekend. Please feel free
to continue the dialog if there are items that still need addressing.
Susan
--
mailto:[EMAIL PROTECTED]
www:http://susanpotter.net
blog:http://snakesgemscoffee.susanpotter.net
linkedin:http://linkedin.com/in/susanpotter
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
