Re: Lua distros again

[Russell Haley <russ.haley@...>]

On Thu, Feb 1, 2018 at 1:23 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> On 29 January 2018 at 22:55, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>> Thank you all for the feedback. My shortlist now consists of:
>>
>> - lpeg
>> - luafilesystem
>> - luasocket
>> - libuv (Luvit)
>> - libcurl (wrapper tbc)
>> - lua-cjson
>> - torch7
>> - luaossl
>> - cephes (wrapper tbc)
>> - luaffifb (port of LuaJIT FFI interface)
>>
>
> I have been thinking about how to go about with this. I want to create
> a harmonious whole on the one hand, on the other, want the ability to
> easily pull changes from the upstream projects.
>
> Seems like the Luadist model is a good fit:
>
> a) Fork an upstream project (possibly create a branch called 'Ravi' as
> I expect to have to tweak some aspects of the project).
> b) Create a submodule in the distro project for each upstream project.
> c) Hook it all up in a CMake based build system.
>
> My goal is not to create a generic package manager for Lua. Nor to
> make it easy for users to pull in additional modules easily. Instead
> the goals are:
>
> 1. Well tested and supported product on Windows, Linux and Mac OS -
> all supported modules installed up-front.
> 2. Binary distros for each supported platform (native installers would
> be nice but I don't know how to do that so initially it may be in the
> form of a self contained compressed archive).
> 3. The installation should not require any system privileges, and
> should just work.
> 4. Long term support and commitment for the distro (i.e. best effort
> to fix bugs and incorporate additional high quality libs) - however
> this does not imply Ravi will keep up with Lua changes, because to me
> 100% backwards compatibility is of paramount importance. I may
> selectively apply changes that are non disruptive.
>
> Regards
>

Josh Jensen has done much of this with LuaPlus too:

https://github.com/jjensen/luaplus51-all