Research on popular rocks on luarocks.org

rocks-research.md

This is a report on the latest non-development rockspecs of all popular rocks on luarocks.org.

Remarks

• Many rockspecs contain build.copy_directories = {}. Does this lead to different behavior than simply omitting build.copy_directories?

• Many rockspecs have "test" in build.copy_directories. They can benefit from an addon that automatically runs these tests (luarocks-addon-test can be extended to do this).

• Some rocks contain a lot of modules and the build.modules table contains a lot of entries that look like ["$package.x.y"] = "$prefix/x/y". Automatic module discovery functionality (like Python's find_package) can be quite useful.

• There appear to be some confusion about whether to use build.modules or build.install.lua to install Lua modules. Do they behave differently with Lua files?

• It seems that many authors are not aware that platform overrides are merged recursively. Also, it might be nice if platforms is supported at all levels, so that one can write the following for instance:

  build = {
      modules = {
          foo = {
              sources = "src/foo.c"
              defines = {
                  platforms = {
                      windows = {"WIN32"}
                  }
              }
          }
      }
  }
  

• It would be nice if luarocks shows a detailed list of what gets installed to where; now it only declares "foo 1.0-1 is now installed in ~/.luarocks" (in case of a --local install) and it is non-obvious where the different files go.

Ideas for addons

• Module discovery
• Support for more platform (e.g. Solaris)
• Messenger: show a message after installation. Problem: there might be messages from dependencies and it makes sense to display the message at the very end of execution (instead of after installing the dependency). This is tricky with the current design.

Appendix: Interesting rockspecs

The criteria for "popular" is 100+ downloads for rocks whose name matches ^[a-h] or 300+ for the others. (The former is the original plan, but I had to raise the threshold since there were too many of them.)

Many rockspecs are considered uninteresting and thus omitted, because they are short, use the builtin build backend and have no intriguing comments.

• cgilua: Uses an iteration to build build.modules from lua file names.

• commandlineui: Contains a dependency that depends on the lua version: luabitop is required on lua < 5.3 and not on 5.3. The rockspec has the dependency commented out, assuming that the user uses lua 5.3. The code, however still requires luabitop and will crash without it on lua < 5.3.

• dado: Contains this comment in dependencies:

  -- no specific version of LuaSQL can be pinned down as a dependency,
  -- since Dado can load any LuaSQL driver at runtime.
  

• dkjson: Depends optionally on LPeg:

  dkjson is written in Lua without any dependencies, but
  when LPeg is available dkjson uses it to speed up decoding.
  

• dub: Interestingly files in build.install.lua are not lua files but other "assets".

• fakeredis: Contains commented out dependencies:

  -- "luasocket", -- only for blocking list methods with timeouts
  -- "LuaBitOp", -- only for Lua 5.1 (not LuaJIT, not 5.2)
  

• feedparser: Contains build.copy_directories = {}. Does an empty table behaves differently from its absense here?

• ffiex: Modules are duplicated in build.modules and build.install.lua.

• haricot: Contains build.copy_directories = {}.

• htmlparse: Contains a "tst" directory in build.copy_directories. Has lunitx as a dependency, but it is only used for running the test cases in the "tst" directory.

• lanes: C + lua. There is some confusion about the platforms windows, win32 and msys...

• ljsyscall: Lots of modules and among them, lots of platform-specifix modules. For instance linux-specific modules reside under syscall.linux.*. Targets luajit instead of mainline lua:

  dependencies =
  {
    "lua == 5.1"; -- In fact this should be "luajit >= 2.0.0"
  }
  

• lmathx: Requires a C99 compiler, I imagine that it will break on platforms where the default CC does not support C99.

• lrexlib-pcre: Claims that it works on 5.1 and 5.2, but also works on 5.3. Lacks a dependency element on lua.

• lrexlib-posix: ditto.

• lua-cjson: Needs platform-specific configuration for Solaris.

• lua-coat: Depends on lua-testmore which is only used to run test cases.

• lua-geoip: All modules have the same incdirs and libraries fields; only the sources fields differ.

• lua-path: Contains the following commented out dependencies:

  -- "luafilesystem >= 1.4",
  -- "alien >= 0.7.0",       -- instead lfs on windows
  

• luasec: C + lua. build.platforms.*.{install.lua modules.ssl.sources} are duplicates (for * = unix, windows). External dependencies are not specified on windows. The former seems like a problem of the rockspec itself.

• luasocket: uses a function to generate build.{unix macosx win32 mingw32}.modules.

• lua-spore: contains a lot of optional dependencies that are commented out.

• lzmq: Contains the following:

  external_dependencies = {
    platforms = {
      ...
      unix = {
        ZMQ = {
          header  = "zmq.h",
          -- library = "zmq", -- does not work !?
        }
      };
    }
  }
  

• magick: contains the following:

  dependencies = {
    "lua == 5.1", -- how to do luajit?
  }
  

• wsapi-fcgi: build.platforms.unix and build.platforms.windows are mostly the same with a few differences.

• xavante: uses a loop to generate build.modules

• xml: build.platforms.linux and build.platforms.macosx are exactly the same.