Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)

[Daurnimator <quae@...>]

On 7 September 2015 at 18:25, Stefano <phd.st.p@gmail.com> wrote:
> On 7 September 2015 at 02:10, Daurnimator <quae@daurnimator.com> wrote:
>>   - Looks like ULua only supports lua 5.1? this isn't mentioned
>> anywhere on your site
>
> Yes, it is based on LuaJIT which is compatible with Lua 5.1.
> I do not have immediate plans to repeat the exercise for Lua 5.2 and
> 5.2, but if there is a enough request for this I might reconsider.

Add "this is a LuaJIT (lua 5.1 compatible distribution)" to the home page then.

>>   - The list is hard to look through; could you make it more
>> browsable? e.g a table?
>
> You are right, it is not optimal for human consumption (it is the
> database used by automated build system).
> I will pre-process it to make it more readable.

Please do so; don't forget to share the link :)

>>       - at least take out the unsupported_external_library errors
>>   - Seems like you don't handle multiple rockspecs under the one name
>>       - e.g. many of lhf's libraries have a different rockspec for
>> each lua version, and the version number is something like
>> 2015-01-01.51 for lua 5.1
>
> The build system should exclude specs which are for Lua 5.2 and above
> and try to build the latest stable (and unstable if above the stable)
> version for the same rock.
> Can you please point me out to a specific rock where this it is not working?

One I noticed this for is "cqueues" (which I maintain the rockspec for)
Notice I have a different rockspec for each lua version
https://luarocks.org/modules/daurnimator/cqueues
In your lists I only see one (in error.lua)

    cqueues = {
      ["20150119.53-1"] = "lua == 5.3"
    },


>>   - Module naming conflicts are hard to solve; all times I've run into
>> them the authors are uninterested/projects have been abandoned
>>       - https://github.com/keplerproject/luarocks/issues/388
>>       - https://github.com/zhaozg/lua-openssl/issues/72
>
> I can manually blacklist rocks.

I'm not sure if blacklisting helping; often both modules are useful.
e.g. for the case of zlib, I prefer brimwork's lua-zlib, but lzlib is
more widely deployed (due to being a dependency of luarocks).

> As you have experience on the topic,  would you have suggestions
> (based on my module conflicts) on which should be so?

As I said... I've never had a good resolution when this has come up in
the past; not sure I can give good advice here.