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. _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
