Quoting halostatue / gmail.com, on Tue, Sep 27, 2005 at 10:29:17AM +0900:
> On 9/26/05, Sam Roberts <sroberts / uniserve.com> wrote:
> > Its not a packaging system, its not an addition to the standard library,
> > it is a change in the behaviour of one of the most fundamental of Kernel
> > methods.
> 
> It is a packaging system, it is an addition to the standard library.
> It *is also* a change in behaviour, but it is one that will behave
> *very preditably* and without harm to those who choose -- through one
> means or another -- to not use RubyGems.

No harm?

You, user of rubygems, state this as supposed fact.

Others, not users of rubygems, do not have this experience of "no harm".

Dismissing all code that is harmed as unncessary is missing the point.
Depending on the language require mechanism to work as they always have
is not wrong, changing it mid-stream is.

> > I fail to see the need for language support for a particular packaging
> > system. I don't see why the need for versioned lib dependencies for
> > rails requires a language change, I don't see why packaging requires a
> > language change, and I don't see why versioned dependencies and
> > packaging are so strongly coupled that you are forced to eat the
> > language change in order to install a library.
> 
> Then you fail to see the point in general. Ruby needs something that
> works similar to -- but better than -- CPAN. This means a packaging
> system. You may not see it, but those of us who have to deal with
> other platforms see it.

Nowhere do I imply that ruby doesn't need a packaging system. I said the
opposite.

In particular, it needs a packaging system that is not tied to
versioning.

> > They should be decoupled, require does NOT have to be changed in order
> > to support package distribution. Split versioning into an optional
> > facility for those who need it.
> 
> This is also a fundamental misunderstanding of what has to be changed.

The require change is for versioning, not packaging.

If you believe that the language change is fundamental to get packaging
"similar to -- but better than -- CPAN", feel free to point out why, and
why such a language change wasn't required for Perl (or C, or ...).

Sam