Re: Lua package manager(s)

[Paul K <paul@...>]

Hi Steven,

> So we've been looking into all our available options. Some of the
> options that users are suggesting and brainstorming involve writing a
> brand-new Lua package manager. Some involve forking LuaRocks itself.
> Some involve writing new tools on top of LuaRocks.

I went through a similar process with ZeroBrane Studio IDE. Some of my
users wanted to be able to install new modules to make them available
from the IDE (especially on Windows and OSX). I looked at the existing
package managers [1] and decided to integrate with luadist; one of the
important points for me was the small number of dependencies (<200k of
lua and <200k of binary modules), which allowed me to include them
with the IDE itself.

> being able to know what packages can be upgraded

I don't think LuaDist provides this "out of the box" either, but the
information about installed and available packages is there, so it
should be possible to write a command that takes care of installing
updated versions.

> it's reasonable to embed it into my application and use it in a Lua-prompt (i.e. REPL).

This is exactly what I was looking for and implemented for my project.
ZBS provides a Lua console and with the plugin I wrote users can type
"luadist.install 'penlight'" and get the required modules and their
dependencies installed. The plugin is a wrapper around commands that
luadist provides; something similar can probably be done for LuaRocks.
By default Windows and OSX users will get binary versions, so no other
dependencies are needed.

This works quite well (both Lua 5.1 and Lua 5.2 modules are supported)
and the biggest issue for me is with binary modules being outdated in
the repository (for example, lpeg is at version 0.10), although you
can always compile from source similar to LuaRocks if you have dev
tools available. Another issue that I've seen is that requiring binary
modules for Lua 5.2 returns Lua 5.1 modules, which obviously doesn't
work.

I'd say LuaRocks is under more active development than LuaDist; even
if you don't want to modify the core modules directly, consider adding
a wrapper that implements the required functionality just for your
product and still reuses the rest of the infrastructure.

There was a long discussion on this very subject about a year ago that
may be of interest [2].

Paul.

[1] http://notebook.kulchenko.com/zerobrane/lua-package-managers-luadist-luarocks-and-integration-with-zerobrane-studio
[2] http://lua-users.org/lists/lua-l/2013-09/msg00740.html

On Mon, Sep 8, 2014 at 11:14 AM, Steven Degutis <sbdegutis@gmail.com> wrote:
> I recently wrote a Mac OS X app[1] that just acts as a Lua host, and I
> wrote some packages for it that let you do things like inspect and
> move windows, bind global hotkeys to arbitrary Lua functions, etc...
> It was called Hydra but the name had to be changed to Mjolnir for
> trademark reasons.
>
> Anyway, there was a lot of disagreement among my app's users for how
> to install packages. So I took out the internal package management
> code I wrote, moved all my modules to LuaRocks, and told all my app's
> users to just use that for their packages.