Re: Core support for Gems, and namespace

On Wed, 28 Jul 2004, Richard Kilmer wrote:

[SNIPped discussion of load path complexity]

Yep, I am quite aware of that from managing perl module installs on 
hundreds of boxes at a time.  Ruby does it basically the same.

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

Yep, perl is the exact same, with the difference that in perl you require 
the object name rather than file name.  Frankly, I prefer it that way, 
because it means that there has to be a direct mapping between object 
space and file space.  If I say 'use Net::LDAP', I know that it's looking 
for a 'Net/LDAP.pm' file.  Of course, there's no guarantee that I loaded 
an object in the Net::LDAP space, but that's the assumption.

I'd actually prefer that with ruby; I want to load objects, not files, so 
it would make sense if I could refer to the objects, rather than the 
files, and let ruby take care of the mapping.  Maybe change 'require' so 
that it looks for files if passed a quote and does a mapping if it's 
passed a class.

[...]
> 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'.

Yeah, I basically get that.

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

Well, it's not so much that I had that world-view before; I was already 
aware that ruby was searching through multiple directories for my 
requested libraries.  I just think it, as they say, is a leaky 
abstraction:  I didn't have to think about the multiple directory thing 
before, and now I do.

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

Heh, I'm certainly not saying that it doesn't solve problems.  I was 
merely questioning whether it solved them the right way.  And really, I 
began this thread because I was looking for some kind of official 
statement as to what the preferred packaging system is.

At least for the time-being, I'll support both gems and rpa-base.

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

Okay, my question is basically answered, then:  There is no established 
standard at this point.  There are a couple of projects out there (mostly 
gems and rpa-base) with very different world-views towards solving the 
same problems, and we'll let the marketplace sort them out.

Further, the namespace issue looks to be largely ignored, at least for 
now.  I'll assume that means that I can put things in what I consider to 
be reasonable subdirectories, then; for instance, I might put my nagios 
configuration generation libraires in mon/nagios/.  I also will do my best 
to make my filespace match my object space, but there's no community 
pressure to make anyone else do so.

Thanks,
Luke

-- 
The salesman asked me what size I wore, I told him extra-medium.
                 -- Stephen Wright
---------------------------------------------------------------------
Luke Kanies | http://abstractive.org | http://reductiveconsulting.com