From: Richard Kilmer <rich@...>
Date: 2004-08-18T00:27:59+09:00
Subject: Re: Recursive install-stub for gems?




On 8/17/04 11:23 AM, "Gavin Sinclair" <gsinclair@soyabean.com.au> wrote:

> On Wednesday, August 18, 2004, 12:17:52 AM, Richard wrote:
> 
> 
> 
> 
>> On 8/17/04 10:04 AM, "Austin Ziegler" <halostatue@gmail.com> wrote:
> 
>>>> On Tue, Aug 17, 2004 at 10:31:15PM +0900, Richard Kilmer wrote:
>>>>>> Why not offer both? That is, give the spec author a simple token that
>>>>>> can be detected to stub everything in the lib directory?
>>>>> Well, because is rather defeats the purpose of keeping the files out of
>>>>> the
>>>>> site_ruby dir.
>>> 
>>> Well ... what's to stop me from listing all of my lib/* files anyway?
>>> 
>>> -austin
> 
>> Nothing stops you, but nothing forces you either.  In most libraries, there
>> is a main file to 'require' (which then requires the rest of the required
>> files) and you document your library accordingly.  At least, with the
>> libraries I write, that is how I design them.  I guess if your library was a
>> random collection of a series of separate files that could individually be
>> required or not, then stubbing every one would make some sense.
> 
> That _is_ the case in one of my libraries, but I reckon that's not
> often the case.
> 
> It does happen reasonably often, though, that a library has several
> potential 'require' targets, some of which will never be loaded unless
> you ask for them.  Rake's not a good example, because it's more an app
> that a library, but it's all that comes to mind at the moment:
> 
>   require 'rake'
>   require 'rake/packagetask'
>   require 'rake/rdoctask'
>   # etc.

Right...and what is cool is if the stub is 'rake' then doing:

require 'rake'

Will move the rake gem into the LOAD_PATH so subsequent:

require 'rake/packagetask'
require 'rake/rdoctask'

Just works, because rakes libs are now fully available (no stubs needed).

-rich