[erlang-questions] [ANN] rebar_escript_plugin

[Tuncer Ayaz]

On Wed, Sep 3, 2014 at 10:08 AM, Tobias Schlager wrote:
> Hi,
>
> the rebar_escript_plugin [1] is an alternative attempt on
> escriptizing applications and releases with rebar. It was written
> out of necessity to be able to package this fileserver utility [2]
> into one executable file.
>
> I hope you will find it useful.
>
> Regards
> Tobias
>
> [1] https://github.com/schlagert/rebar_escript_plugin
> [2] https://github.com/schlagert/serve_it

Hi Tobias,

thanks for sharing the project(s), and here are some comments based on
a quick look at the sources, which I hope you'll find useful:

(1) runs automatically as post_compile or post_generate hook

We've been discussing support for user defined aliases like the
built-in prepare-deps and refresh-deps. The motivation is something
else, but it could also make this more convenient.

==> can be made more convenient in rebar, and this also touches on the
topic of being able to select config variants on the command line.
Related:
https://github.com/rebar/rebar/issues/58
https://github.com/rebar/rebar/issues/206
https://github.com/rebar/rebar/issues/283

(2) avoids the necessity of duplicate configuration

rebar escriptize cannot unconditionally include all deps in the
escript for obvious reasons, but if this is a common use case, it'd be
easy to add a rebar.config switch that default to off.

==> can be folded into rebar upstream

(3) provides a default main/1 function, starting all needed
applications as a normal Erlang release would

We could do the same, but I'm not sure there is a single way to start
an escript. Your runner seems to spin up all bundled apps and wait for
termination, but is this generally applicable? Does it work with all
all kinds of escripts, including interactive tools?

==> can be folded into rebar upstream, if there's consensus on
runner behavior

(4) makes your application's priv directory contents accessible at
runtime

The plugin extracts priv into a temp directory, and while that works,
the long-term solution is to teach escript and erl_prim_loader to do
the right thing. We should also add a convention (filename, etc.)
based way to bundle arch-specific files (e.g. .so, .dll).

==> not sure this can be folded into rebar upstream

(5) additionally allows escript creation based on release
specifications

==> can be folded into rebar upstream