On Thu, Oct 28, 2004 at 11:31:05PM +0900, Chad Fowler wrote:
> # "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".

Exactly... with the exception that it's got nothing to do at all ;-)
with what we're talking about :))) So it's more like apples and oranges.

> # 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. 

And it's good so. I was trying to explain the differences between
RubyGems and rpa-base, you shouldn't interpret it as an attack. The
fact is that RubyGems supports several versions of a lib at a time,
and rpa-base works differently and features what I've called "strong
dependency management".

These differences illustrate that RubyGems and rpa-base have different
goals, and that it is indeed a good idea for RPA not to throw rpa-base
away to embrace RubyGems: after all, rpa-base was designed for RPA.

Both codebases are useful for their respective niches and we're looking
forward to increased cooperation especially given your recent commitment
to making RubyGems repackager-friendly. I can tell you that many ppl are
looking forward to that and we (I can't really speak for the whole RPA
team because we're quite busy in general, but at least I) will try to
help you make that happen.

> 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've explained in the past that this is a known UI issue that will be
solved when we get our new UI framework in place. There's a reason for
rpa-base being 0.2 ;)

Anyway, I wonder what that well known UI issue in rpa-base has got
to do with RubyGems' lack of "strong dependency management" given the
above definition.

> 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.

It is possible to indicate which dependencies shouldn't be uninstalled
when their rev-depends. are removed. IMHO this should be a configuration
option and it will be handled that way in the new UI.  I believe
rpa-base's new configuration system and UI framework could benefit
RubyGems so we'd be happy to contribute it when it's finished.

If you want to let the user choose (to match the "we don't think you
are an idiot" philosophy you profess) what to do, you will need a
garbage collector for the packages. I might try to adapt rpa-base's for
RubyGems but I'm not sure it's practical because its versioning model
makes it harder to track (reverse) dependencies.

> As for tracking reverse dependencies, it doesn't seem difficult to me:
> 
>   spec.dependent_gems

Well you're obviating the code behind *g* But there are still some problems
you'd run into if RubyGems tried to do everything rpa-base does
regarding reverse deps, etc... This is probably better discussed on IRC
or on your ML though.

> 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.

Choice is good. Having a system provide guarantees so that the user
doesn't have to bother about things that can be handled automatically is too.

> 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."

I am sure we all love dynamic typing but it doesn't really have anything
to do with this :) 

I use rpa-base myself and I surely don't call myself an idiot *for that*
(there are many other better reasons ;)

-- 
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com