Re: Distributing self contained lua app

[Paul K <paul@...>]

> I'm wanting to make a small lua application completely self contained, no installation dependencies. So my plan is to use physfs so that all the lua scripts would be in one file.
>> I don't think there are any easy answers for what you are trying to
>> accomplish here.

I agree with Sean here, but will propose another option.

There has been an interesting project developed by Justine Tunney
(https://github.com/jart) that produces cross-platform binaries and
has recently added support for Lua 5.4.3 (actually slightly earlier,
but compatible version). It also supports embedding files and reading
them from a zip archive, so does something very similar to what physfs
would do in this case. I've recently contributed lsqlite support for
it, so one could also access SQLite DBs from those scripts if
necessary.

The project is redbean (which is a lightweight http-server) and it's a
part of a larger Cosmopolitan project
(https://github.com/jart/cosmopolitan). If you take a redbean binary
(https://redbean.dev/), you can then do the following:
1. Add .lua directory to it with whatever Lua libraries you have as a dependency
2. Add .init.lua file with whatever Lua code you'd like your
application to run (and do `os.exit()` as the last command, otherwise
it will launch an http server).
3. Launch redbean.com (after "chmod +x" on Linux/macOS).

That's it. What you get is a binary that runs on Windows, Linux, and
Mac and executes your Lua code without unpacking anything (or leaving
any other trace in the host system). All "require" commands will find
the libraries in the .lua folder, so nothing special needs to be done
to support this. Dynamic libraries are *not* going to work, but it
should be possible to add additional modules statically (in fact,
there is a ticket for LFS:
https://github.com/jart/cosmopolitan/issues/215) and it should still
be possible to write a DL support in the future (here is a ticket for
it to discuss: https://github.com/jart/cosmopolitan/issues/137).

To spend a few more minutes on this project: cosmopolitan not just
minimizes external dependencies; it doesn't have any, as it
re-implements libc for all supported platforms in the code that is
included in the binary itself. In fact, you can configure it to strip
TLS/SSL support and remove SQLite support, which will probably
generate a binary that is going to be 300kb or so in size and still
provide all the functionality needed to satisfy original requirements
across all supported platforms. The reason Redbean is proposed (even
though it's a webserver) is that it already implements all the
necessary components, but something similar could obviously be done
without any HTTP-handling code. This is just something that would work
out of the box, even though it does more than is needed.

Paul

On Thu, Jul 22, 2021 at 4:25 PM Sean Conner <sean@conman.org> wrote:
>
> It was thus said that the Great Peter Hickman once stated:
> > I'm wanting to make a small lua application completely self contained, no
> > installation dependencies. So my plan is to use physfs so that all the lua
> > scripts would be in one file. Then I will use a little C script like this:
>
>   [ snip ]
>
> > I'm pretty sure that it will work just fine. But there is a question,
> > physfs is a nice and small library and I only need three methods so it's
> > not a big deal. But if I was to use SDL2? Exposing the whole of SDL2 (sdl2,
> > sdl2_gfx, sdl2_image, sdl2_mixer, sdl2_ttf) as C functions is going to be a
> > nightmare. Along with the issue of getting SDL2 to use physfs when it loads
> > images, fonts and sound files
> >
> > Is there a better way of doing this?
> >
> > Or is it "welcome to the club" :(
>
>   Welcome to the club.
>
>   Okay, I do this for a few applications at work, only I embed the entire
> code (C and Lua) into an executable.  I have an overview of how it works:
>
>         http://boston.conman.org/2013/03/22.1
>         http://boston.conman.org/2013/03/23.1
>
> only these days, I load the C modules into package.preload and I run the Lua
> based modules through zlib to save space.
>
>   I also did another approach to distributing a "Lua application" as a
> single file, based off the method Java uses with it's .jar files.  An
> overview of this method:
>
>         https://github.com/spc476/LEM
>
>   There were, however, some issues---while I could load modules written in
> Lua directly from the ZIP file, I could not load modules written in C
> directly from the ZIP file (I would have to first extract the module onto an
> actual file system and then I could load them).  Also, how to deal with
> applications that want to write data.  I was able to get LuaRocks to run
> exclusively from a ZIP file (but that work isn't publically avilable as it
> was more of a "proof-of-concept" for myself than anything else), and
> ultimately, I just lost interest in it.
>
>   But on that note, the ZIP file format is unique in that its header starts
> at the *end* of the file, so it's relatively easy to append a ZIP file to
> the end of an exectuable (that's how self-extracting ZIP archives work).
> Maybe a self-extracting/self-installing program?
>
>   I don't think there are any easy answers for what you are trying to
> accomplish here.
>
>   -spc
>
>