Re: LuaRocks survey

[Nagaev Boris <bnagaev@...>]

On Sun, Jan 31, 2016 at 5:48 PM, Marc Balmer <marc@msys.ch> wrote:
>
>> Am 31.01.2016 um 15:24 schrieb Nagaev Boris <bnagaev@gmail.com>:
>>
>> On Sun, Jan 31, 2016 at 4:39 PM, Marc Balmer <marc@msys.ch> wrote:
>>>
>>>> Am 31.01.2016 um 14:10 schrieb Nagaev Boris <bnagaev@gmail.com>:
>>>>
>>>> On Sun, Jan 31, 2016 at 4:02 PM, Marc Balmer <marc@msys.ch> wrote:
>>>>>
>>>>>> Am 30.01.2016 um 18:26 schrieb Etiene Dalcol <dalcol@etiene.net>:
>>>>>>
>>>>>> Hey folks,
>>>>>>
>>>>>> We had some discussions about the ecosystem recently, specially concerning how exactly people decide to share or search external libraries, both here at the mail list and during FOSDEM's devroom.
>>>>>>
>>>>>> Next month I'm gonna spend a month volunteering to LuaRocks' website and I decided to make a survey to see if my priorities are on point or if there are things me and Leaf overlooked! I also enjoyed the opportunity to talk to Hisham and add some questions relevant to him and the LuaRocks tool itself
>>>>>> "
>>>>>> Would you please answer some questions?
>>>>>>
>>>>>
>>>>> Done.
>>>>>
>>>>> Though I am thinking of starting a discussion about Lua ecosystems, the need for them (or not), here online.
>>>>>
>>>>> My main concern, in all brevity:  How could someone who does not use LuaRocks (me) still make sure his (mine) stuff can be used by someone who uses LuaRocks (you)?
>>>>>
>>>>
>>>> I would publish my work as is, announce it here and ask somebody to
>>>> make a rockspec for it. LPeg rock seems to be created like this.
>>>
>>> I actually did this.  Several times even, especially for luapgsql (github.com/mbalmer/luapgsql), but no success so far.
>>
>> I have tried to install it:
>>
>> $ luarocks install --local luapgsql
>> Missing dependencies for luapgsql:
>> lua >= 5.1, == lua, < 5.3
>> Error: Could not satisfy dependency: lua >= 5.1, == lua, < 5.3
>>
>>
>> The problem is in the lua version field. It is set to "lua >= 5.1, lua
>> < 5.3". Replace it with "lua >= 5.1, < 5.3".
>
> That is the technical reason and it's easy enough to fix.  The real issue here, however, is, that we (aka my company) are not rock users and we work on commercial software (we have to feed some mouths and pay some rents, too), so we have only limited resources to invest in stuff we don't even use.  Otoh, we think that our code can often be useful to others, so we publish it under an open source license.  And yes, we think our code is of general good quality and is used for production in many installations, many of them mission critical.
>
> I totally agree with Etiene D'Alcol when she said in a previous mail that a directory of freely available Lua software/modules is needed, and yes, that directory can well be LuaRocks (although the wiki lists a fair amount of modules as well).
>
> What we'd really love to see is someone who want's to see (or use) the software we publish under an open source license in LuaRocks, someone who likes to package stuff and make it available, like the good folks packaging third party software for Debian, FreeBSD ports, or, pkgsrc.  I used to be such a person myself in OpenBSD some years ago, so I know the drill.  I just don't have the time to do it, neither my colleagues.  We could  "play" the role of "upstream", always having an open ear for such a rockspec person.

I see. Probably Lua community needs a group of maintainers of such
rocks. Most of us are likely to feed some mouths and pay some rents,
so it is not easy to find such a group.

Maybe there is already such a group, but they are uncoordinated.

I propose the following solution. Broken / unmaintained rocks and Lua
packages without a rock are reported to
https://github.com/keplerproject/luarocks/issues Those volunteers who
has time, convert them into rocks and upload to the LuaRocks server.

> What we currently think _is_ of use:
>
> github.com/mbalmer/luapgsql
>
> What we currently think _could be_ of use:
>
> All the other stuff on github.com/mbalmer/
>
>>
>> For more information about the rockspec format, see
>> https://github.com/keplerproject/luarocks/wiki/Rockspec-format#Dependency_information
>>
>>
>> --
>>
>>
>> Best regards,
>> Boris Nagaev
>>
>
>



-- 


Best regards,
Boris Nagaev