[Rubygems-developers] RubyGems Dependency Type
drbrain at segment7.net
Sun Feb 3 19:40:14 EST 2008
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?
> * 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
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
>>> 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.
More information about the Rubygems-developers