Re: RubyGems in Ruby HEAD

Hi --

On 9/21/05, Austin Ziegler <[e-mail]> wrote:
> 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.)

Glad I don't use Perl ;-)

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

Well they may have over sliced it but it's hardly HARD. As for
including all these things, I don't want Tcl/Tk on my system for
instance. So I can't agree with you. Some of these libs have outside
dependencies, so their inclusion should be weight carefully. In
thinking about it perhaps it is as simple as having two packages, a
Ruby main and Ruby extras.

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

Indeed that would help. And it would be nice if that was standard behavior.

Also, would it be better if gems were stored in site_ruby? Personally
I could care less about the distinction and have been known to link
/usr/local/ right back to /usr. Nonethless, I wonder if it is is more
proper to FHS/LSB. (And though you might not care, obviously others
do; so if they can be accomidated w/o too much sacrifice...)

Thanks,
T.