From: Chad Fowler <chad@...>
Date: 2004-10-28T23:31:05+09:00
Subject: Re: Gems as key? Re: The real Ruby vs. Python.



On Thu, 28 Oct 2004, Mauricio [iso-8859-1] Fern�ndez wrote:

# On Thu, Oct 28, 2004 at 09:08:08PM +0900, David A. Black wrote:
# > On Thu, 28 Oct 2004, Mauricio Fern�ndez wrote:
# >
# > > If you really want to use rpa-base (maybe you need atomicity or strong
# > > dependency management?), take a look at the above link and feel free to
# > > ask :)
# >
# > Clarification, in case anyone misunderstands:  I don't know what your
# > threshold is for "strong", but Ruby Gems has dependency management,
# > and I haven't seen anything non-strong about it.
#
# "Strong dependency management" means that the system ensures no invalid
# state (where the dependencies are not fully satisfied) can be reached.
# In that sense, RubyGems' dependency management isn't "strong".
#

"Strong" as in "Strong typing".

# The problems are fairly subtle and easy to overlook; I myself didn't
# notice them at first when working on rpa-base.
#
# RubyGems' versioning model makes it difficult to track reverse
# dependencies: currently user intervention is required to ensure no
# dependencies are broken on uninstall, and the installation/removal
# of a RubyGems package plus its dependencies isn't performed as a
# transaction. There are also some essentially unsolvable issues at runtime
# (unsatisfiable dependencies).
#

Most of this is by design.  An example of something that I believe is
broken from an end-user perspective in rpa-base is that when I remove a
package, it removes all of the dependencies.  We _don't_ want to do that
with RubyGems.  I have Rails installed, and I've written scripts to use
ActiveRecord, which was installed with Rails.  If I decide I don't want
Rails anymore, I don't want to have to go manually install ActiveRecord
afterward.

As for tracking reverse dependencies, it doesn't seem difficult to me:

  spec.dependent_gems

The manual user intervention you were talking about is not _necessary_.
We added it because we wanted the user to have the choice to remove a
package even if it might screw something up.  I see it as being in the
same vein as allowing a programmer to pass a String into a method that may
usually expect something else.  "Here's some rope...you can use it to tie
knots, secure things, etc. or you can hang yourself with it.  We trust
that you'll make the right decision, because we don't think you're an
idiot."

Chad