Hi all,
As part of my work on ULua [1], I routinely go through the task of trying to install the Lua rocks from
luarocks.org (root manifest) on Windows, OSX and Linux.
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 missing!
+ builds which should work but fails in the most creative ways (I am easily amused)
+ 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 above.
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 [2].
More precisely, could you please:
1. Check wether your Lua rock pass or fail at [3]. If it pass, champagne! Otherwise...
2. Check wether it fails due to a platform-independent error (like contending the module name) at [4]. If so, please fix and celebrate accordingly. Otherwise...
3. Check wether it fails due to platform-dependent errors at [5]. 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 [6]. 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 [4] 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 [7] 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 2.1.
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 3.0-rc1.
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 [8] is 'no, "enforce semver to all rock authors!" is not possible'.
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 [9] 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 hand.
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 ecosystem.
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.
Yes, I can use Python or _javascript_. However I cannot help but notice that Lua is a preferable option both from a language and from an implementation perspective.
Bests,
Stefano
