Re: Core support for Gems, and namespace

On 7/27/04 8:21 AM, "Luke A. Kanies" <[e-mail]> wrote:

> That's exactly the behaviour I want to avoid.  It seems that that is
> confusing packaging requirements (i.e., this package should only be
> installed if these other packages are installed) and loading requirements
> (when you load this package it needs to load all of these other packages).
> The loading requirements are already easily handled, as long as developers
> don't have to care whether the packages are gems or not -- just 'require'
> the correct libraries.  As to packaging requirements, that should be a
> completely different solution, because run-time problems are completely
> different from install-time problems.


Luke,

On my machine Ruby's $LOAD_PATH is set to:

 "/usr/local/lib/ruby/site_ruby/1.8",
 "/usr/local/lib/ruby/site_ruby/1.8/powerpc-darwin",
 "/usr/local/lib/ruby/site_ruby",
 "/usr/local/lib/ruby/1.8",
 "/usr/local/lib/ruby/1.8/powerpc-darwin",
 "."

Cool, fine...when I install a third party library it typically goes into:

"/usr/local/lib/ruby/site_ruby/1.8"

Excellent.  I install something, say jabber4r, and it installs all its files
there.  Now, I want to uninstall it.  Oh, its a shared directory with LOTS
of files in it...hm...which ones did jabber4r install???  Or, better, I want
to upgrade a library.  The new files are overwritten, cool, but there may be
cruft files left there that are no longer used.  The point is with all these
files in one directory the chance of picking a file of the same name as
another library is certainly possible, and cleaning things up can be a PITA.
Realize that in Ruby there are actually two distinct namespaces:

1) The filesystem (require, load, autoload)
2) The 'objectspace' (module, class)

The $LOAD_PATH is concerned with the former, the later is just one big
shared (dynamic) namespace of nested modules, classes, etc that is
constructed as Ruby loads files.

So, RubyGems manages the $LOAD_PATH for you, increasing the manageability of
the filesystem namespace.  It dynamically adds to the $LOAD_PATH directories
that point to 'gems' that you say you need.  You package your stuff up in a
gem, it gets installed in its own (version specific) directory.  Each
directory/gem is distinctly manageable.  You say you want a library, and
RubyGems (first) adds the gem's directory to your $LOAD_PATH, then (second)
'requires' the files that make the library usable.  This later 'feature' is
optional.  So, what require_gem does, actually, is manage the $LOAD_PATH.
Its almost like an 'import' statement or better 'extend_load_path'
statement.  After that, require performs its normal operations, traversing
directories under each gem path/shared path looking for the files you are
trying to 'require'.

I realize that RubyGems adds to the 'complexity' of your scripts, because
the simple worldview of one-big-directory is no longer valid, and you have
to think of versioning...but that (albeit small) complexity brings
significant flexibility both in:

(1) manageability: adding/removing/updating libraries (locally or remotely),
generating documentation, browsing documentation, sharing libraries, etc

(2) versioning: you can have one script require a gem that requires an
earlier version of library X and another script that requires a gem that
then requires a different version of library X running at the same time
(though not in the same interpreter instance).

Anyway, having produced lots of Ruby libraries, I can tell you that RubyGems
does solve problems, and makes Ruby more flexible and manageable.  You may
disagree, that that's ok.  We are certainly evolving RubyGems (we are not
yet at 1.0) but 1.0 is not too far off.

Once 1.0 occurs, and when the community begins adopting it (producing and
consuming gems), the discussion with Matz can progress with how to more
seamlessly integrate RubyGems with the Ruby language to (perhaps) make
require take and optional version argument and do what the core RubyGems
runtime does in require_gem (managing the $LOAD_PATH, etc).

Best,

-rich