Re: Core support for Gems, and namespace

On Wednesday, July 28, 2004, 10:50:22 PM, Mauricio wrote:

> On Wed, Jul 28, 2004 at 11:29:53AM +0900, Gavin Sinclair wrote:
>> I don't want to ram library versioning down anyone's throat, but on
>> the one hand, you say you don't like the fact that RubyGems bothers
>> with versioning (it's overengineering, and you don't see a use for
>> it), and on the other hand, you point out two very good reasons to
>> have it: allowing apps/libraries to cope with changes to APIs in other
>> libraries; and avoiding "CPAN upgrade hell".
>> 
>> Since there are two good reasons to tackle versioning, why not embrace
>> it?

> You are implying that the options are
>  * tackling library versioning as done by RubyGems
>  * not doing anything about it
> However, RubyGems' way to solve that is not the only possible solution.

I certainly didn't mean to imply that.  I was just fishing for
comments.

The rest of your post is very interesting; I'll just make one
comment...

> RPA will be doing "full version sets", which means that all libs within
> a RPA release will work well together. See the 2nd point in 
> http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_FAQ .
> One will be able to have several RPA releases installed simultaneously.

> Regarding Austin's example, diff-lcs-1.0.2 would replace diff-lcs-1.0.1
> in the last RPA release, so nobody would install 1.0.1 anymore (they'd
> get 1.0.2). diff-lcs-1.1.0 would be shipped with a later release.
> End users/developers can choose between:
> (1) committing to the API from a particular RPA release: at that point,
>     you use all the libs *from that release*. No need to perform
>     cherry-picking with a  require "foo/requirements".

... cherry-picking is not necessarily a bad thing.  In fact, I don't
see why it's even to be avoided.  A coder knows what their
dependencies are, and will test their code with certain versions of
those dependencies.  There's no dependency set in a Ruby project
that's so large as to be beyong the capability of one person to
manage.

That's not to dismiss the RPA approach one jot.  Its emphasis on
quality is excellent.

Cheers,
Gavin