On 9/21/05, TRANS <transfire / gmail.com> 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 * halostatue / gmail.com * Alternate: austin / halostatue.ca