From: TRANS Date: 2005-09-22T01:50:33+09:00 Subject: Re: RubyGems in Ruby HEAD Hi -- On 9/21/05, Austin Ziegler 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.