Re: RubyGems in Ruby HEAD

On 9/21/05, TRANS <[e-mail]> wrote:
> I'd like to add 2 cents about libraries being added to std. Ruby in
> general: I don't think it's good. Here are my reasons.
>
> 1) People have different use cases for Ruby and being straddled with a
> large set of libraries that will not be used is unnecessary bloat.

I don't particularly agree with this. The standard library for Ruby is
still smaller and more featureful than the standard library for Perl.
(The Win32 ActiveState download for Perl is, last I checked, nearly
20Mb. The Win32 installer for Ruby is about 9Mb.)

> 2) Some package maintainers know the above and have gone to lengths to
> split the distribution into it's many parts, eg. Debian. While that
> can be a bit annoying for Debian users, the end result is a cleaner
> system.

Except that the Debian team got it *wrong* by making it really hard to
install a usable set of Ruby libraries. It's much better now, but no
other language was so badly sliced. I've argued this before -- if it's
in the Ruby core distribution, it's part of Ruby. That means zlib, that
means OpenSSL, that means *all* of it. And it *needs* to mean RubyGems.
I'd argue that it should probably include Archive::Tar::Minitar and the
RubyZip stuff, but that's because these are both useful libraries in
general.

> 3) Having separate libs allows one to install newer versions of things
> before the next version of Ruby itself is even out.

This is still possible. My $LOAD_PATH puts my site Ruby directories
BEFORE my standard library directories. The search order should
*probably* be:

  site_ruby
  gems
  standard
  .

> 3) It puts greater burden on Ruby's main developers.

Not really true all the time.

> Having said this, RubyGems or kin, is something that I think SHOULD be
> included standard. As it would facilitate an increased exclusion of
> other libs, which could instead be easily installed on demand via this
> vehicle.

This is true.

-austin
--
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]