lua-users home
lua-l archive

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


Thanks Paul. I'll look into this.

On Mon, Sep 8, 2014 at 2:10 PM, Paul K <paul@zerobrane.com> wrote:
> 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.
>