lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 


This was not the exact itch I had in mind with the subject.
In order to get to proper use of LuaRocks, we must first manage "who's doing what" on the coding/design side of modules.
( some modules are already fine; those managed by Kepler, LuaSocket, Lanes I would say. ) 

I suggest to:

	+ use 'tolua' or other such "automatic" binder, whenever possible
Simply because they usually tend to create the shortest code possible for a binding (easier to maintain and to see the essentials). They also make bindings more uniformed than hand crafted code (easier to understand multiple bindings). 

	+ gather people into "clans" interested in a certain binding
I myself would be willing to offer time to testing and development of: Cairo, SDL, D-BUS. If I know I'm not alone in the project, and I know that it's "the" version that's going to be used by all.
+ no single person should be irreplacable for any of the "clanned" modules
Since it's not only about our talent, but about our schedules, as well. There should be min. 2-3 active people per module. Any one of them being able to fix any bug in the modules. 

	+ backwards compatibility
Module APIs should _not_ be broken, unless in an experimental branch and/or changing the version number. 

	+ documentation
With loads of selftests, and example code. This is _vital_ for anyone taking up the module.
It's all about pulling multiple weak strings together here, and making a rope. We mostly just want modules "to work" (and that is the virtue of CPAN on Perl) instead of building our own or debugging the one we found. But it does not seem to come about just by itself. 

-asko



David Manura kirjoitti 15.1.2009 kello 6:15:


On Wed, Jan 14, 2009 at 4:53 AM, Michal Kolodziejczyk wrote:

Michal Kolodziejczyk wrote:
1. create a "lua open software repository" (LOSR) which would list all 
known libraries, its homepage, status, short description.
It would be ideal if anyone could contribute (filling a web form, or
uploading a simple text file). Possibly it could be based on luarocks, 
so people could upload their rockspecs, and possibly source tar.gz
archives. I like the way the archlinux' aur.archlinux.org works.


BTW, hackel's hackage at http://hackage.haskell.org/ would be better
example.


As I see it, hackage.haskell.org (Haskell), aur.archlinux.org (arch
linux), and search.cpan.org (Perl), all share a common structure.  A
package is an archive (zip or tar.gz) containing module source, a
package descriptor file, and sometimes other things like docs and
tests.  These packages can be indexed by a bot and presented in a
unified web-based interface.  There can even be multiple such web
interfaces independently maintained (e.g. CPAN has search.cpan.org and
cpan.uwinnipeg.ca) since anyone can write an interface for the
repository.

The framework for doing this in Lua is already there: LuaRocks[1] and
LuaDist[2] packages.  Someone just needs to write some scripts to
parse one (or both) of these repositories and present them in a web
interface.  The page [1] actually already does that but only in a very
limited sense compared to the Haskell/Linux/Perl examples above.

Earlier, I had set up LuaSearch[3] to index POD documentation for Lua
modules, but it didn't catch on.  However, this predated some of the
developments in LuaRocks and assumed people would use POD.  Today, I
would recommend instead the approach outlined above of indexing
LuaRocks/LuaDist repositories.  Perhaps, one would expose it through
Sputnik in a way similar to how Sputnik indexes mailing lists[4], but
this is only one of the possible implementations.

Even if we do maintain a central repository of Lua modules, there is
still something lacking.  A discussion that has come up a number of
times[5-7] on the Perl mailing lists concerns a need to independently
document the relationships between modules: this module supersedes
another module, this module is no longer maintained by the author,
here is a detailed review of the merits and differences of many
modules that overlap in functionality, etc.  In short, a user wants to
do "X" (e.g. X = "do bitwise operations"), but the user has a
difficult time finding and comparing the prior art of modules covering
X.  Personally, I think the Lua wiki, which is flexible and adaptable
to different purposes, is just fine for this.  A number of recent
pages[8-17] follow this basic concept of a review page that compares
multiple modules that are centered around a shared goal X.  Modules
here don't even need to be formally packaged and indexed, they don't
need to be registered on LuaForge, and they need not even be
restricted to "modules" (but rather patches and design patterns)--you
just link whatever you have to the wiki page and add whatever
discussion is most appropriate.

Perl also has a mailing list ("perl.module-authors") dedicated to
people authoring Perl modules.  Topics include naming of modules,
proper packaging, testing, API design, and asking for feedback on a
proposed module implementation.  It's an area for collaboration
between module authors.  This may be useful for Lua to mirror,
although the regular Lua and LuaRocks mail lists may sufficiently
cover such discussions.

[1] http://luarocks.luaforge.net/rocks/
[2] http://luadist.sourceforge.net/
[3] http://lua-users.org/wiki/LuaSearch
[4] http://lists.luaforge.net/pipermail/sputnik-list/2009-January/000443.html
[5] http://www.nntp.perl.org/group/perl.module-authors/2008/04/msg6386.html
[6] http://www.perlmonks.org/?node_id=513313
[7] http://www.nntp.perl.org/group/perl.module-authors/2004/07/msg2615.html
[8] http://lua-users.org/wiki/ModuleReview
[9] http://lua-users.org/wiki/BitwiseOperators
[10] http://lua-users.org/wiki/LuaBuildSystems
[11] http://lua-users.org/wiki/UnitTesting
[12] http://lua-users.org/wiki/GraphicalUserInterfaceToolkits
[13] http://lua-users.org/wiki/ObjectOrientedProgramming
[14] http://lua-users.org/wiki/MultiTasking
[15] http://lua-users.org/wiki/LuaImplementations
[16] http://lua-users.org/wiki/BindingCodeToLua
[17] http://lua-users.org/wiki/TableSerialization
[18] http://www.nntp.perl.org/group/perl.module-authors/