Re: Lua Recipes Site?

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

On Sat, Sep 19, 2009 at 6:25 AM, steve donovan wrote:
> I've been chatting to Yuri (of Sputnik fame) about the mechanics of
> putting up a searchable 'Lua recipes' site....
> [1]  http://www.delphidabbler.com/codesnip

A lot of us have been advocating package management practices for
modules (e.g. LuaRocks).  But what should we do about single isolated
functions (e.g. a string split function [1])?  Like modules, these
functions can benefit, in terms of reusability, from unit tests,
metadata, versioning, and a unique versioned URI for citation.  For
convenience, we usually deploy these entities differently via manual
copy/paste + a citation comment rather than via luarocks install +
require.  It's also preferable for these functions to be published
easily and rapidly via the web, not distracting users with the package
management tasks like building and extracting tarballs and setting up
tools.

The Lua wiki indeed serves some of the above purpose.  It does lack
strong versioning and traceability (the wiki in fact eventually throws
away history).  The embedding of code in a wiki page is somewhat
unstructured too.  Given a Lua Recipes site, wiki pages remain useful
and could cite the recipes via some structured tag, e.g.
[LuaRecipe:12345], and the wiki might even download and display that
snippet in-line.

The Lua recipes site could translate recipes to LuaRocks packages that
can be loaded via "foo = require 'luarecipes.id12345'", it could
expose them in an svn repository, and it could index LuaRocks
repositories to cross-reference modules that cite the recipes (which
also can be used for ranking popularity).  These services can be
transparent to web users and don't need to be implemented immediately.

A fundamental question is what is a recipe.  The rockspec format [2]
may provide a starting point.  For example, a recipe has a unique
identifier, an author/maintainer, a license, and a description (or
external URL).  A recipe may be immutable.  A recipe may supersede or
provide an alternative to another recipe, and these relationships may
be navigated.  A recipe may have unit tests that can be executed in a
standard way (e.g. automatically by the Lua Recipes site in a
sandbox).  The code may depend on other recipes or LuaRocks modules.
A recipe may be tagged with categories.  Some recipes may be pure Lua,
while others may involve C, some may be single functions, while others
may be multiple files, and the user might want to filter results based
on these qualities.

[1] http://lua-users.org/wiki/StringRecipes
[2] http://www.luarocks.org/en/Rockspec_format