[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: To all Lua rock maintainers (also included considerations on Lua's ecosystem and a Lua distribution)
- From: Daurnimator <quae@...>
- Date: Mon, 7 Sep 2015 11:10:47 +1000
On 7 September 2015 at 06:58, Stefano <firstname.lastname@example.org> wrote:
> Hi all,
> As part of my work on ULua , I routinely go through the task of trying to
> install the Lua rocks from luarocks.org (root manifest) on Windows, OSX and
> Problems include, but are not limited to:
> + rocks contending the same module name, who doesn't love 'json'?
> + rocks polluting the module namespace with generic names - anyone using
> 'test'? - worsening the problem above
> + missing supported OS and required external libraries specifications
> + no automated way of building such required external libraries
> + no standardised build tool: make, cmake, nmake, automake...just lake is
> + builds which should work but fails in the most creative ways (I am easily
> + wrong dependency requirements
> The exact three OS I have used are by no means esoteric:
> Windows7 64 + Visual Studio 2015
> Latest stable OSX + bundled Clang
> Ubuntu 10.04LTS + gcc 4.8
> It follows these problems are representative of the average user experience.
> Even libraries with a certain fame, like LuaSocket, are not immune to the
> Up to 2 months ago the latest LuaSocket stable version did not build on
> Windows/MinGW and required googling + manual patching of the rockspec (on a
> side note, for a couple of years before that it also injected globals and
> was incompatible with strict.lua and similar).
> Trying to improve this situation I would, as a first step, kindly ask for
> the cooperation of Lua rocks maintainers. Even if you don't care less about
> my project, you can still threat it as an automated build-test framework
> (stricter than Luarocks), which in a sense it is. All info is found at .
> More precisely, could you please:
> 1. Check wether your Lua rock pass or fail at . If it pass, champagne!
> 2. Check wether it fails due to a platform-independent error (like
> contending the module name) at . If so, please fix and celebrate
> accordingly. Otherwise...
> 3. Check wether it fails due to platform-dependent errors at . If so,
> please fix and celebrate accordingly. If not...
> 4. It means your rock depends on something that is not available as can be
> seen at . Please blame or blackmail whoever is responsible, or fix your
> broken dependency.
> You should *not* be concerned with two errors:
> 1. module_conflict errors in  that are due to multiple *related* rocks
> pointing to the same module (example: metalua-compiler and metalua-parser
> both contending the metalua module): these will be supported shortly
> 2. unsupported_external_library errors: I am not going to support these
> shortly (aside from selected libraries which I will package manually) but
> there is nothing that you can do about it
> Finally, Luarocks stdout and sterr for each rock are logged into  for
> your convenience.
> The fixes will automatically propagate to ULua, should it concern you.
> Example, for the case of Copas:
> 1. Damn, it failed!
> 2. No errors here...
> 3. No errors here as well, who is to blame...
> 4. Me! I am depending on a never existed and never going to exist LuaSocket
> What follows are my personal considerations around Luarocks and the Lua
> ecosystem, so if you are only interested in helping out improving the rocks
> you can stop reading here (links [*] at the end of this e-mail).
> So, the dependency for Copas is "luasocket >= 2.1" and Luarocks accepts
> I personally find this reason for concern and not for relief (different
> major version, and it's not even a stable release!)
> The stated position  is 'no, "enforce semver to all rock authors!" is not
> Despite that, only a tiny minority of rocks has dependencies targeting a
> specific version (some do not list version requirements at all, I guess
> their maintainers have given up).
> Hence, lacking agreement on the meaning of numbers, any new rock can
> potentially wreak havoc. Yes, upgrades are not supported. But any rock that
> installs today maybe will not install tomorrow.
> I wonder how that is preferable to assuming semver and accepting that some
> modules do not follow it.
> More generally, the version format specification is documented  as
> "please look at the source code".
> Also, rocks which contend the same module but are unrelated (json4lua,
> luajson) are not rejected. All these details point to a 'lack of policy'
> which I find detrimental to the Lua ecosystem.
> This lack of policy has a much wider scope and has been popularised with the
> "mechanism not policies" phrase. I am fine on this idea being applied to the
> language itself.
> But in the specific context of modules/packages this mindset does not work.
> I am not referring to the lack of a module() function (which, as
> implemented, I am glad disappeared), but:
> + agreement on module responsibilities (no globals ever, ...)
> + agreement on version format, on its meaning, and on the module metadata
> + agreement on an extended standard library (*everything* IO included, ...)
> + agreement on Lua compile flags (what type is a number? which compat
> options? which conversion options? ...)
> + agreement on documentation and tests
> All this necessarily has to come from upstream. Yes, the Lua team blessing
> Indeed, language-wise, Lua has been perfectly suited as a general purpose
> language since 5.0, that's 12 years ago, and as of today there are no
> satisfactory solutions to the points above nor a particularly healthy
> If the idea was "let's leave this to the community: a natural selection
> process will yield an optimal result", then it clearly has not worked.
> I am happy that Lua is light and customisable and that this contributes to
> its success in embedded systems and as a glue Language.
> It would be great if steps were taken to offer also a pleasing experience as
> a general-purpose programming language.
> This would take the form of a batteries-included version (side by side to
> the light version already available) plus answers to the +s above.
> Lua is a preferable option both from a language and from an implementation
> --- the web --
>  http://www.scilua.org/ulua.html (a binary Lua distribution for Windows,
> OSX, Linux)
>  http://www.scilua.org/luarocksorg/state
>  http://www.scilua.org/luarocksorg/state/pass.lua
>  http://www.scilua.org/luarocksorg/state/error.lua
>  http://www.scilua.org/luarocksorg/state/target_os/target_arch/log
>  http://article.gmane.org/gmane.comp.lang.lua.general/112719
>  https://github.com/keplerproject/luarocks/wiki/Rockspec-format
- Looks like ULua only supports lua 5.1? this isn't mentioned
anywhere on your site
- The list is hard to look through; could you make it more
browsable? e.g a table?
- 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
- Module naming conflicts are hard to solve; all times I've run into
them the authors are uninterested/projects have been abandoned