[ruby-talk:7520] Re: Ruby RAA

"Joseph McDonald" <[e-mail]> wrote:
>
>Thanks for the excellent input Ben!

You are welcome.  One point I think that cannot be made
strongly enough.  What matters is not just having things
there, but rather having confidence that the wheels which
are there, will work as advertised.

Also while CPAN is often cited and does indeed work well,
IMHO Debian (http://www.debian.org/) has tackled a similar
problem and done a better job.

> > 1. Have a core team managing the namespace, testing, and
> >    telling people about duplicated functionality.
>
>Does CPAN do that?  I see a lot of duplicated functionality.
>not that that's a bad thing, different strokes for different
>folks I always say.  But a nice summary of similiar modules
>by an impartial would be nice (witness the numerous templating
>modules on CPAN... how do you pick?).

Yes, there is a team of testers that serves an advisory role.

They mainly test whether it builds on different platforms,
and tell the author about similar modules, and advise on
possible namespace conflicts.  Authors still decide
whether or not to proceed, and frequently do if they think
that their module does something different.

How do you pick a templating module?  Well I listen to
Randal Schwartz and pick Template::Toolkit. :-)  Seriously
do take a look at it.  Of all of the template solutions to
emerge in the Perl world, it is by far the best.  If Ruby
wants to produce its own templating solutions, that one
would be an excellent model to work from.  (I think that
second is Text::Template.  But it is far less flexible.)

See http://search.cpan.org/search?dist=Template-Toolkit
for details.

> > 2. Have a standard tool ("perl -MCPAN -e shell") to interact
> >    with CPAN.
>
>Agreed!  What makes it *king* is the dependency checking and
>automatic installs of dependencies. (although it doesn't always work...)

Likewise look at Debian.

> > 3. Have the standard installation save important local
> >    information in a way that module authors can use.
>
>you mean for bug reporting?

That or for installation.  Try "perldoc Config" and take a
look at what is available.  All of that information is
captured by Perl at install time, and when you try
"perl Makefile.PL" any and all of that information can go
into the makefile.

> > 4. Have a standard directory layout decided at installation
> >    for where things go.
>
>agreed.  key.
>
> > 5. Have a standard method of inlined documentation,
> >    automatic regression tests, etc.
>
>key.  especially the regression tests.
>
> > 6. Have a standard packaging tool (h2xs) for producing
> >    modules in a standard format.  (Making the entire
> >    "make Config", "make", "make test", "make install"
> >    process standardized across modules.)
>
>would probably have a huge impact on people placing their work on
>RAA.  the biggest drag is getting something "distribution ready"
>pure grunt work, rubyites (and perlites) don't want to be bothered
>by such drab work.

Exactly.  When you look at CPAN, the parts of the proceedure
made automatic by h2xs happen consistently.  The parts that
do not are inconsistent and often don't happen.

Likewise take a look at Debian and debmake.  Debian is a very
consistent system despite being put together by a distributed
group, and a large part of that is having clearly decided
policies on where things go, and a standardized packaging
tool that makes it easy to follow that policy.

> > 7. Have a standard way to check versions, state
> >    dependencies, and so on.
>
>Do you mean that the user could say:  puts $class.version; $class.depends ?

Perl doesn't do a great job on this.  But if you assign to
$VERSION in a module, then people requiring the module
can put a version check into the load, and the CPAN tool
can detect whether or not your version is sufficiently
up to date.  But this is optional and doesn't happen as
consistently as it should.

Debian does a much better job on this.  They have a
standard packaging format for their package (the .deb
archive) that carries version information.

> > 8. Have a standard tool to check whether you have
> >    indeed done it right.
>
>okee dokee

For instance if you say that your dependencies are Foo and
Bar, it should load your module and see if there is some
other Baz out there that you are loading as well. :-)

> > 9. Have a standard bug reporting mechanism for installed
> >    modules.
>
>Amen.

Perl doesn't have this and really, really needs it.  Debian
does and it really works.  It is critical to be able to go
to a single place and browse open bug reports.  It also is
an excellent way to detect when something is not really
being maintained any more.

Today there is no good way of finding out which CPAN modules
are buggy and which are not.  There is no good way to find
out whether someone has already pointed out the bug which
you have to report.  There is no good way for an eager
volunteer to find out what needs to be worked on.

I cannot stress enough that Perl got this seriously wrong.
And once people have their own ways to handle these things,
it would be very hard to just go and say, "OK, here is the
new bug-tracking system, everyone has to use it."  This
has to be gotten right from the start.

>I'd add the obvious: good search mechanism and good hierarchical
>organization.  CPAN has that (although it does break more than
>it should IMHO).

Yes.

>Also, I know there is a movement to categorize applications as well
>as modules on CPAN.  That is also a good idea.

Another shortcoming.  CPAN's system is only good for modules,
which is one reason that there has been room for some of the
other application archives out there...

A final note.  The most successful model to emulate IMO is
Debian, not CPAN.

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com