LuaSearch - towards a search.cpan.org for lua modules

[David Manura <dm.gmane@...>]

When a Perl programmer approaches a new language, such as Lua, that
programmer senses something is lacking and asks where is the CPAN for
that language.  Even if you're among those not fond of the Perl
language itself, I think it's less debatable that in CPAN Perl got
something right, and a few languages (e.g. Ruby) follow suit.

What CPAN follows are sound software engineering principles.  There is
a consistency of module documentation practices, testing practices,
location, installation, dependency resolution, pragmatism,
etc. adhered to by thousands of module authors.  It's not perfect, but
it's better than what Lua has, and it has worked exceptionally well in
practice.

So, we see this concern comes up again in the recent "Lua's
opportunity" thread, and it bugs me enough that I've decided to
attempt to do something about it.  But the task at hand seems not
something that can be resolved in a day...or is it?

If I were to identify what I like most about CPAN, what I would most
want to bring into Lua given limited time and resources, it is not
necessarily CPAN itself but the "POD" documentation format and
conventions applied to modules in CPAN, as well as the CPAN search
engine, search.cpan.org, whose main function is to consistently expose
this POD documentation and module "metadata" in a central place.

What is POD?  POD is primarily used to document modules.  It contains
distinct sections to address, with no nonsense, each of the main
questions you would ask when discovering a new module:

  What is it's name, namespace, and version number?
  What does it do?
  What does the client code look like?
  What is the interface?
  What are the dependencies?
  How do I obtain/build/install it?
  Who wrote it?
  What is the license?
  Where do I send feedback?
  What are the related modules and how do they differ?

One common goal here is to make discovery and sifting through modules
much easier/faster, consistent, and less confusing.

In formatting, POD is simple and minimalistic, but flexible, almost
like a wiki syntax.  There are preexisting tools to parse it and
render it as HTML with indices--great.

So, to begin, the task is quite simple: rework Lua documentation into
POD and expose it consistently in a centralized web site.  So, about
five hours work later rehashing docs for about a dozen selected Lua
modules into POD, converting it to HTML with pod2html, and modeling it
all after it's Perl cousin search.cpan.org (though with certain
features lacking), LuaSearch was born:

  http://lua-users.org/wiki/LuaSearch

The basic idea is there, enough to convey and gather interest from
others in this project.

Now what is to be said of LuaForge?  I believe LuaSearch can actually
build upon the capabilities already present in LuaForge.  In the
interest of LuaSearch, LuaForge provides a place for storing modules,
registering modules, and authenticating developers.  LuaSearch could
index the modules, files, and metadata stored in LuaForge, and in this
way LuaForge can be thought of analogously to some functions of a Lua
CPAN.  In what LuaSearch intends to do, providing a more *interface-
and client-centric view* of available modules, I think LuaForge falls
short, though possibly it could be brought into LuaForge, but I'm not
a LuaForge developer, nor even a seasoned Lua developer with all the
answers, but I think it's important to first introduce the concept.

Simple and accessible solutions are the ones that work in practice.