Re: Why not just ONE of each module?? (Re: Lua binding for d-bus?)

[Bertrand Mansion <lua@...>]

On Wed, Jan 14, 2009 at 10:43 AM, Michal Kolodziejczyk <miko@wp.pl> wrote:
> Etan Reisner wrote:
>> On Wed, Jan 14, 2009 at 08:05:01AM +0200, Asko Kauppi wrote:
>>> As a generic comment, I think it would finally be time for Lua community to
>>> develop this kind of modules in an organized fashion.
>>>
>>> There's so many of them. D-BUS. Cairo. SDL. Multiple incompatible and
>>> partial modules instead of a One that would be co-managed by the community.
>>>
>>> I think this is where we go wrong, and which keeps Lua back as a language.
>>>
>>> -asko
>>
>> I agree about the need for organization of this sort of thing, but I doubt
>> it much keeps lua back as a language though (unless you want to claim that
>> with the organization we'd have fully formed working bindings for these
>> things already which would be, I think, something of an exaggeration).
>
> I agree that community support would be extremly helpful. There is
> plenty software for lua, but if it is not on the luaforge, it could be
> hard to find it.
> I think the way to go would be to:
>
> 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.

I have bought losr.org just in case. I liked the name, makes me think
of looser :)
The LuaRocks format would be perfect for such a repository in my opinion.

> 2. I always hoped that eventually there will be "community supported
> library" (something like perls' CPAN, so CLAN for lua, or PHP's PEAR),
> which would provide a global namespace for each module/library (like
> Graphic.Cairo. Graphic.SDL etc). This again could be based on luarocks
> (the "more official" repository)

I have been involved with PEAR — PHP Extensions and Addons Repository
— for a very long time (8 years). It was successful until Zend, the
company behind PHP, created Zend Framework. All of a sudden people
started to contribute a little more to Zend Framework and a lot less
to PEAR. Some started their own frameworks... I think this had to do
with marketing and too much bureaucracy. PEAR also had the goal to
have only one package per project (for example, you could not have two
packages to deal with web forms). In the long run, I think this was
wrong because competition between packages authors can boost
productivity and it is important to offer choices.

So for a good CLAN I suggest ythat competing LuaRocks be allowed if
they can fit a certain standard of quality. For a successful
repository of high quality Rocks, here is a list of what I have
witnessed while working on PEAR:

- Define coding standards
- Have an automatic API documentation system
- Have a wiki or some kind of CMS for Rocks tutorials
- Have a command-line distribution/packaging/installation system
- Make it clear who is the author and maintainer of a Rock, since it
is a responsibility
- Have a bug tracker
- Have download statistics for instant gratification
- Have a flexible category system which could be used for namespaces,
ie Graphics.Cairo
- Have a central website which give a nice interface to browse the packages
- Have a validation tool on Rocks uploads
- Have mailing list for users and one for developers

There is no need to have a central SCM to take care of the Rocks code.
Devs should be free to use whatever they need. But it is important to
be able to browse the source online without having to download it.

Building such a site and community is a lot of work and time. It is a
good thing that we already have LuaRocks.


> 3. So I think it would be best to choose some libraries (those which are
> in "workning state") from LOSR and assign them a place in the CLAN
> hierarchy. I imagine the process should be similar to what Lua for
> Windows guys are doing - there should be as many different versions in
> LOSR as people can create, but only one module at given time for any
> given funcionality should be "blessed" by CLAN (like bitlib vs LuaBitOp
> issue)
>
>> I think the problem tends to be that people work on bindings like this by
>> themselves and either are unable to release them or never get to the point
>> where they feel like they can share them. So the next time someone needs
>> one they have to start their own, and we start the cycle again.

In this case, having LOSR and CLAN different options is a good thing
because people might feel more comfortable to release code in a loose
fashion on LOSR then other people might pick their code and clean it
(api doc, coding standards, ...) for CLAN. This is a good idea and
something that was missing in PEAR.

> Very true. For some (most?) projects there is no point in creating
> luaforge project (yet - at this early stage), but the lua community
> could be "informed" about it by creating an entry describing it in the LOSR.
>
> Regards,
> miko

-----
Bertrand Mansion
Mamasam