Re: Lua Distributions and Package Management

[Peter Drahoš <drahosp@...>]

On 27 Sep, 2013, at 8:30 , Paul K <paulclinger@yahoo.com> wrote:

> Hi Peter,
> 
>> This is an incorrect install of LuaDist. You are probably running LuaDist using an interpreter that was not installed using LuaDist itself thus it does have information about itself in share/luadist-git/dists directory that stores “dist.info” files about all installed packages, this is very similar to what LuaRocks does with rocks.
> 
> You are right about what happened: I ran into issues bootstrapping, so
> I just copied the files and ran LuaDist from my own interpreter.
> 
>> Therefore the install function decided that it needed to pull in lua also. Note that it also decided to use source code which it does by default but setting lib/lua/dist/dist.config “source” setting to false will disable all build features and pull in only binary modules if available.
> 
> It's nice to see that the settings and type/arch can be configured
> before requesting the binaries. I still need to figure out where
> exactly modules are installed, but so far the possible integration
> looks promising. Do you also have binaries for non-Windows platforms?

OSX and Ubuntu binaries are available but I can upload any architecture binaries to the repositories (this even works on Solaris), at the moment I am working on Lua Continuous Integration service that will generate all the binaries once modules are submitted in source. For linux I still need to work out some details to make it cross-distribution compatible (glibc version mismatch issues and some other minor linking issues).

> 
>> Michal Kottman already proposed and partially implemented a module that does exactly this based on LuaDist[1]. This is very much a proof of concept but it shows the possibilities.
> 
> Thank you for the link. I saw that and it seems to be very close to
> what I have in mind; maybe with some additional parameters to possibly
> request installation of modules for a different Lua version.

LuaRocks already has/had require that takes version constraint as second parameter, that would work in this context also.

> 
>> I agree that this is an issue. LuaDist “solves” this by using separate install folders for different interpreter versions. This was the most straightforward way to implement it on most platforms without issues. ZBS could simply contain separate subfolders for each interpreter.
> 
> I have something very similar (clibs and clibs52 include modules for
> different Lua versions), but there are still some shared folders and
> having one lualib may require a bit of trickery on Windows.

In my experience on Windows the separate dirs approach solves almost all problems. Duplicate files may be an issue but with shared data folders this will be pretty minor inconvenience. Also note that LUA_CPATH and LUA_PATH can point to a shared folder first and then into the interpreter specific subdirectory for ease of development of backwards compatible modules or apps.

pd