Re: Lua library bank?

[Andrew Starks <andrew.starks@...>]

On Tue, Mar 12, 2013 at 12:33 PM, David Heiko Kolf <kolf@gmx.de> wrote:

<snip>

I have to take a closer look at LuaDist myself as well.  Does it offer a
united build process where I could take the entire default distribution
and say "./configure && make" (or similar) and have all the modules
built at once?

I suggested a new namespace for modules in a standard package to
indicate that for those modules the original authors no longer take sole
responsibility but that they are considered as core modules where
multiple volunteers can update or even replace them in a central
repository and new versions of the entire library are discussed on this
list before fixing a release.  And I would not suggest to rewrite all
the common modules -- if the API looks good, there would be no reason to
reinvent wheel.

Best regards,

David Kolf

I'm resisting the urge to fork this again (Started as ruby, came here, shadows over in (smart)lua version 1 and 2...)

I did take a look at LuaDist. There are a handful of things that *I* would do differently. But, I also wouldn't follow any project that did it the same way that I did... I've been around enough of those...

LuaDist is... I'm sorry to those who may disagree, but it's "perfect enough."

On Git (and GitHub): Implementation detail. I don't think of git as the source control, in this context. I think of it as the module distribution and management system. Git is a fine technology choice and I'm having trouble thinking of a simpler way to do it across platform.

On Structure: the "one directory" approach works well, when one considers it has to work everywhere. I believe that this is the main problem that L4W had. It was "other". Now we have a model that uses what every system has in common (relative paths in a common tree) and it doesn't stray too far from what people have seen before. If they want a more integrated approach, there is LuaRocks, which presently doesn't work well in the weirder worlds.

On CMake: Again, it's a reasonable choice. Back when it was made, was there any other reasonable choice? Now, one could argue that Lake or Premake4.3 could be beaten into submission. Too late now and from what I can see, there isn't anything all that wrong with CMake. Looking at the instructions for making a Lua module, it doesn't seem that hard to me. [1] 

Basically, it works really well and it has the huge feature of being an *implemented decision*. It's here now. Since there is nothing that is glaringly wrong with it, it seems like a decent enough project to rally around.

[Also, there is a much better flow for those that want a common install directory-ball and a "package by package" rocks-like interface, than what was there before. I don't really want the batteries, but I would use this to manage my packages and updates.]

I do think that there needs to be a better naming distinction between "LuaDist" the project that makes it possible to manage a package library and "LuaDist" the Lua repository that is acting as an eco system.

Also, I think that things will get really fragmented and you'll loose mindshare if you go with "Lua4Windows" and then "Lua4Mac", etc. Maybe not, but how much mindshare is there with Lua4Windows and could it be fixed with a redirect? It feels like Lua4Windows is trying to capture momentum that might be there, but it's carrying the legacy of a project that couldn't be reasonably ported to other platforms that may want something like it.

--Andrew

[1] https://github.com/LuaDist/Repository/wiki/Example%3A-Lua-module