On Thu, Oct 28, 2004 at 05:49:02AM +0900, Its Me wrote:
> > This is something we (the RPA team) consider infeasible; RubyGems does
> > not have the capabilities we believe necessary.  This is both in terms
> > of RubyGems presently being less technically advanced than rpa-base,
> > and in terms of one key capability: The ability for RPA to modify the
> > technology to suit our needs.
> 
> I am sure there are things you need beyond core Gems. But there is such a
> core of rubygems (at least notionally; I don't know the architecture) that
> directly overlaps a core of RPA: installing a package, knowing dependencies,
> and installing dependees.

RubyGems installs packages in separate directories; it supports multiple
versions of a lib at a time but it is not totally transparent (you need
a combination of the "require hack" plus executable stubs, and the
datadir issue is yet to be addressed).
rpa-base installs atomically into $prefix; the operations are transacted
and it is transparent; it can track reverse dependencies and GC packages
on uninstall. It can also do parallel installs and update itself.

Even the basics are quite different. The basic, fundamental operation
(installing a package) is arguably stronger in rpa-base because it
is atomic. This is an absolute must because rpa-base manages files
in $prefix.

There is no gain in throwing away a codebase that works well and
replacing it with another that does NOT do what RPA needs, the way it
needs it. 

However, we have tried to share code when possible, and it is in that
spirit that we contributed rpa-base's package format code to RubyGems,
which was integrated as of 0.8.0.

> module Gem; require_gem 'Core'... end
> module RPS; require_gem 'Core' ... end

The deep differences even in the core operations make this approach
impossible.

> > This is a large task.  The present rpa-base and package set only
> > scratch the surface of what we're trying to do.  We're presently
> > looking at the next step in the enabling this:
> >
> > - A new version of rpa-base that support the development cycle for the
> > above much better (integration with version control system to make
> > maintenance of code uniform etc)
> > - Documentation to help more people be able to do RPA packaging
> > - Documentation and checklists for helping software quality
> > - Building a review team for doing code review for code we import into the
> RPA
> > - Support for binary packages, to make Ruby deployment on Windows etc
> easier
> > - Increase in team size
> 
> These are great, and 100% valid. It's just that there is a core that seems
> identical, Imho.

Well, it just isn't... Note that the development of rpa-base
began in February; by the time RubyGems 0.2.0 (first public
release) was out, in 2004-03-14, rpa-base was already doing atomic
installations/upgrades/deletions, handling extensions, RDoc generation,
automated unit test runs, etc. I just mention that to illustrate that
the development of these two codebases happened in parallel, and that
different design and implementation choices were taken on each.

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