Including other people's Ruby libs in your package

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

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.

I'm familiar with it, and while it's often true, it may not have to be.

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

That's beginning to sound like work for all involved.

In principal, having multiple copies of a lib laying around shouldn't have to be a problem. Disk space is now cheap. Having a copy of something in local relative directory shouldn't be an issue if the code that wants to use it is the only code that knows about it. Many libraries take less space than the accompanying change log files that list every minor alteration since day zero.

Packaging trivia: The tar.gz file for BlueCloth 0.0.4b is 38kb. The bluecloth.rb file, the one that actually does the work, is 31kb uncompressed.

James

"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