[ruby-talk:01562] Re: Ruby library modules and documentation

(Found on comp.lang.misc.)

Dave Thomas <[e-mail]> wrote in message
news:[e-mail]...
> "Conrad Schneiker" <[e-mail]> writes:
>
> > It might be a good idea to document these as not being further
documented
> > and to individually identify which ones are obsolete (and its
successor),
> > and which ones of the toys or perlish ones that others would be free to
turn
> > into something more useful (unless there are problems with backwards
> > compatibility).
>
> You know, I've been thinking that it might even be a better idea to
> reorganize the current library somewhat.
>
> Right now, there's stuff in lib/, some of which is useful, some not
> so. Then there a heap of useful stuff in RAA.
>
> So, I'm thinking that maybe there needs to be four library trees:
>
>    supported, distributed        -- final, observer, etc
>    unsupported, distributed      -- English, ..
>    supported, not distributed     -- irb, benchmark
>    unsupported, not distributed  -- ?
>
> To qualify for the 'supported' category, a library module must:
>
> 1. Be documented with rdtool
>
> 2. Install automatically
>
> 3. Have a set of regression tests
>
> 4. Pass those tests with the currently supported release of Ruby

Presumably this is to _initially_ qualify, or for _subsequent_ changes to
qualify. It would also be useful to make the regression tests for all the
<supported, distributed> modules be a criterion for pronouncing any given
release of Ruby to be a "stable production ready" level, and perhaps to have
a "make lib_regression" (perhaps in a supplementary distribution package)
for everything in the <supported, distributed> category, so as to validate
installations on our differing platforms.

> 5. Fit in to the library directory hierarchy (which is yet to be
>    defined, although matz is starting to migrate some stuff into
>    lib/net/).
>
> This last point is important. As the size of the library grows,
> keeping it organized will become a challenge unless we impose some
> structure from the start.

Are any further considerations needed for the future Ruby variant of CPAN
(Comprehensive Perl Archive Network)?

(Suggested pronouncable designation (at least in English): the Extensive
Ruby Archive, since Ruby marks a new ERA in colaborative component
computing.)

> The nice thing is, all these criteria can be tested automatically as
> part of the overall Ruby testing process, so we can actually cut down
> on effort at the same time we add value.
>
> As the current number of library modules and RAA entries is relatively
> small, this is a great opportunity to set some standards that will
> make Ruby an easy language to _manage_ on user's systems.

This is extremely important for winning mindshare. This is also an important
consideration for some large fraction of perspective Ruby users in many
mid-sized corporations where harried sysadmins not infrequently can
substantially help grant or help hold up permission to use new tools.

This would also greatly help to make Ruby the preferred means of producing
and delivering configuration management systems (among many other things)
for much less easy to manage systems of all kinds, ranging from user's
personal systems to multitudes of gigantic far-flung mixed vendor networks,
and so on.

Conrad