Re: Wishlists and Modules (was [ANN] libmc)

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

On Wed, Sep 2, 2009 at 4:22 AM, steve donovan wrote:
> Although code may be free (in both senses of the English word) it can
> still be expensive in terms of time needed to understand it.
> In an ideal world there would be as little friction as possible in the
> process, i.e. that when using a new module, the accidental complexity
> should be as little as possible. (May well be essential complexity,
> sometimes things _are_ rocket science.)

I suspect this friction contributes to the reinvent-the-wheel
phenomena, the perception or reality that reinventing is the simplest
way to ensure that requirements are met.

> A The ideal module:
>  0 well named (using namespaces)
>  1 well focused
>  2 well contained
>  3 explicit dependencies
>  4 documented in some standard way
>  5 adequate test coverage
>  6 useful examples

Among other Kwalitee measures [4], this is particularly desirable:

    7 automated configure+build+deploy from source

Most of that can be summed up as "consistency" (a la CPAN and APT).

> B And the ideal package manager:
>  1 handles dependencies
>       (must do this automatically, like LuaRocks [1])
>  2 integrated documentation
>       (must be available from a central index after installation, e.g
> like perldoc)
>  3 specifies external dependencies in a useful way
>       (in an ideal world, it use the native package manager to find these)
>  4 searchable for capabilities and module names
>       (e.g. that the module 'lfs' corresponds to the package
> 'LuaFileSystem' - new LR will do this)
>  5 flexible tag-based classification
>      (so we aren't tied to a inflexible fixed hierarchy, like the
> Trove system [2])
>
> It seems hard to do B2 without A4, without resorting to hacks &
> heuristics (is there a README? is there an index.html, perhaps in an
> 'en' folder? ...) So naturally there have been Lua people interested
> in the Perl POD format.

More than two years ago, I started LuaSearch [1], loosely modeled on
the hugely popular search.cpan.org, but it didn't catch on.  I think
the main problems were

  C1) This was before the establishment of centralized, easy to crawl
module repositories such as LuaRocks [2] and LuaDist [3] (apart from
LuaForge).

  C2) It assumed users would agree to use a particular doc format (POD).

If this were done again, I would not impose hard restrictions C2 in
documentation format but would use heuristics to render as best it can
whatever it is given.  I would, however, provide incentives to follow
one of a couple conventions (e.g. README.txt, LuaDoc, POD, Kepler
style HTML, POD, etc.).  I would also automatically crawl
LuaRocks/LuaDist repositories rather than rely on manual submissions.

Given the developments in C1, I think there's a strong case that
someone with the time and inclination should re-pursue this.  It's
actually not that much work to get it basically running.  It can be
managed independently of the LuaRocks/LuaDist projects.

[1] http://lua-users.org/wiki/LuaSearch
[2] http://luarocks.luaforge.net/rocks/
[3] http://luadist.org/repo/luadist/ ; http://lua-users.org/wiki/LuaDist
[4] http://cpants.perl.org/kwalitee.html