Re: Lua Ecosystem

[Justin Cormack <justin@...>]

On Wed, Nov 27, 2013 at 2:55 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> On Wed, Nov 27, 2013 at 7:06 AM, Justin Cormack
> <justin@specialbusservice.com> wrote:
>> On Wed, Nov 27, 2013 at 10:36 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>> 2013/11/27 Justin Cormack <justin@specialbusservice.com>:
>>>
>>>> We are going to brutally decide on a best interface and officialize it.
>>>> Somehow. But its going to happen...
>>>
>>> 1. Who are "we"?
>>
>> Any interested parties.
>>
>>> 2. Please define "officialize".
>>
>> Approved by said interested parties.
>>
>> If you don't like, ignore or fork.
>>
>> Justin
>>
>
> Justin,
>
> My pithy response aside, Dirk's questions combined with your reaction
> seems like an important thing to consider.
>
> Generally, people that *push* for a better repository system or a
> standard "batteries included" library have a vision for a world where
> Lua is adopted and used as Perl or Ruby. Dirk's questions point out
> that Lua's success isn't in that realm. Where it *is* enormously
> successful, you'd have a hard time getting people to bring in a
> library system or allow their scripting users to do so and so "we" and
> "officialize" are important terms to define.
>
> Unfortunately, I sound discouraging. I think I'm just trying to say:
>
> As you go about this awesome work (which I support and am not
> against), remain aware of the fact that anything that sounds like
> policy is going to be aimed at what is currently a niche user.
>
> It's hard to imagine that anyone wouldn't welcome a cleaner and more
> navigate-able library, even as they won't use it in their projects and
> only as long as it doesn't impact their ability to use Lua the way
> that it is, right now.

Actually the Lua like thing to do is to provide mechanisms, so maybe
this should be pitched as a way of supporting a useful ecosystem of
working and co-working Lua packages, a way to install them,
repositories, CI, reviews and so on. But there can be multiple such
sets, eg your internal company repo, your embedded stuff with size
constraints and so on. These may overlap in terms of packages they
support. Maybe most people would use the "desktop batteries" but there
would be other ones.

Justin