[Rubygems-developers] RubyGems Dependency Type

[Eric Hodel]

On Jan 30, 2008, at 10:32 AM, Susan Potter wrote:
> The following is the scheme I used at my client (but with a few
> client-specific things thrown in that I will not discuss here as they
> aren't relevant for solving *this* particular problem):
>
> * each dependency when defined has a "type".  I have personally used  
> the following types for Ruby to make more sense for our world:  
> runtime (default), compile (for Ruby/C extension purposes), test.
>
> * on "gem install" (unless otherwise told) the runtime dependencies
> are installed only.  I added a flag to the gem CLI (again through
> extension).  Of course, this again only works in our internal, fully
> controlled system.
>
> Here is my proposal open to feedback since my background is primarily
> in the server-side enterprise space (I am directly answering Eric
> Hodel's questions from below):
>
> * should developer dependencies by installed by default?
>>> No
> * what does the command-line option look like?
>>> gem install -Dall or gem install -Dtest or gem install -Dcompile
>>> test installs runtime AND test dependencies.  compile installs
>>> runtime AND compile dependencies.  all installs all three: runtime,
>>> compile and test.
> * what happens on uninstall?
>>> ???  The client implementation I have currently only uninstalls the
>>> given gem(s), but this needs further thinking as I realize this is  
>>> not
>>> optimum.

Mainly, this is in regards to `gem uninstall --ignore-dependencies`,  
which dependencies should be checked?  Should we add the -D flags to  
uninstall, or stick with just checking runtime dependencies (I think  
the runtime-only is most beneficial).

> * what should `gem check` do if all dependencies aren't installed?
>>> in my proposed implementation I have found it useful to only check
>>> runtime by default, but if -D is specified it will check those as  
>>> per
>>> the CLI option noted above.

`gem check` is supposed to run the tests, so should it may need to  
inform the user that the test dependencies are missing.

> To be honest, I think the thing that matters most is that RubyGems
> provides a way to describe this metadata and then we can worry about
> tools and facilities to wrap around this later.  If people do not want
> to set the extra dependency type, that is fine, we default it to
> runtime and Gem developers aren't any worse off than they are now.

As in, all dependencies are runtime by default?  Sounds good.

> If you want to do extra things based on RAILS_ENV or MERB_ENV or
> another environmental setting you can do so with something like
> GemInstaller or another RubyGems "extension".  In fact, I think simply
> adding the metadata property of Gem::Dependency#type (ok, we use #kind
> because of #type history) to RubyGems gives greater flexibility rather
> than only providing one facility (e.g. GemInstaller, that you
> essentially have to be married to).  We can even defer how people
> handle installing using these dependency types to third party Gems
> instead of involving RubyGems in that business.

As in, RubyGems provides only runtime, compile and test dependencies,  
but allows people to define other types?

> 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.  Unfortunately I cannot just open source the client work I
> have already done since it is considered proprietary.


I'd really like to see something like this added to RubyGems, provided  
I don't have to do all of the heavy lifting.  If you have the time,  
please contribute it.