From: Nicholas Van Weerdenburg <nick@...>
Date: 2004-07-30T14:30:51+09:00
Subject: Re: Including other people's Ruby libs in your package

"Cost-Schedule-Scope" is my prefered triangle. "Quality is free" applies 
to most current software processes and products due to the cost of 
defects and defect levels. The initial extra effort in quality (and a 
large initial effort at that) doesn't impact schedule at all- in fact, 
it may shorten it. TDD is a good example- 50% of your code as test, and 
faster delivery of cheaper higher quality software to boot.

Of course, quality is relative. Releasing a comic-book wiki (comiki?) 
built to aerospace quality standards would be expensive and foolhardy :).

I'm a lazy power user.  I'm spoiled by RubyGems now- if a library isn't 
provided via it, I must really need it to download it :). So I want the 
complete Grandma+Hacker package too. Actually, I'm starting to hate 
Windows because I have to INSTALL software one piece at a time. Fink, 
ports, and the like are incredible. And anything sophisticated will have 
a lot of dependencies- that's progress with big better solutiosn being 
built on top of higher-level abstractions and components.

Personally, I humbly beg for good, automated dependency management with 
visibility and control into issues/conflicts/choices.

A common chain-of-responsibility pattern like used by Java classloading 
might be interesting to explore (though I suppose this would be more a 
Ruby architecture thing in general). Tomcat is particularly cool, with 
each webapp having it's own classloader. Different versions of the same 
library can be loaded into the same JVM, but won't be seem by the other 
web-app due to library being bound to the the webapp classloader only.  
A common system area is available for shared libraries, and tomcat 
itself has it's own private classloader. If a private classloader fails, 
the request for a class is propagated up the chain to the "common" 
classloaders, until finally no more class loaders exist in the chain, 
and a ClassNotFoundException is generated. Java 1.4 (and maybe 1.3) also 
has this chaining of classloaders for the JVM itself, with a precedence 
for finding and loading classes. On the other hand, this can give some 
wild bugs when a completely different library then the one you expected 
is being loaded.

Nick

Mehr, Assaph (Assaph) wrote:

>>Both.  Complete control with a minimum of fuss (why must there be a
>>    
>>
>choice?).
>Are you familiar with the classic triangle of quality-speed-price? You
>can only choose two out of the three for any project.
>
>  
>
>>My hope would be such that there would at least be a default lib
>>    
>>
>installed, but that
>  
>
>>it would not take precedence over any existing files, not stop anyone
>>    
>>
>from simply
>  
>
>>installing a preferred version.
>>    
>>
>
>How about a command-line switches with intelligent defaults? E.g.
>--with-bluecloth=system
>
>  
>