lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 7 September 2015 at 06:58, Stefano <phd.st.p@gmail.com> wrote:
> 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
>
> --- the web --
> [1] http://www.scilua.org/ulua.html (a binary Lua distribution for Windows,
> OSX, Linux)
> [2] http://www.scilua.org/luarocksorg/state
> [3] http://www.scilua.org/luarocksorg/state/pass.lua
> [4] http://www.scilua.org/luarocksorg/state/error.lua
> [5]
> http://www.scilua.org/luarocksorg/state/target_os/target_arch/error_sys.lua
> [6]
> http://www.scilua.org/luarocksorg/state/target_os/target_arch/excluded_sys.lua
> [7] http://www.scilua.org/luarocksorg/state/target_os/target_arch/log
> [8] http://article.gmane.org/gmane.comp.lang.lua.general/112719
> [9] 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
      - https://github.com/keplerproject/luarocks/issues/388
      - https://github.com/zhaozg/lua-openssl/issues/72