[erlang-questions] [ANN] rebar_escript_plugin

[Tuncer Ayaz]

On Wed, Sep 3, 2014 at 3:49 PM, Tobias Schlager wrote:
> Hi Tuncer,
>
> thank you very much for your feedback! Let me make clear, that I
> didn't want to bash rebar's escriptizer in any way. rebar is a great
> project and I would be glad to contribute some of the plugins
> functionality if you would like. The only reason I went the plugin
> way was because I wanted something that everybody can use
> immediately without patching their (committed) rebar.

Plugins are a good choice for trying out ideas, and in this case most
of it is upstream-worthy.

> Your comments and critics are always welcome! My thoughts about your
> points:
>
> (2) Why not? As of today, there's no way to specify different types
> of dependencies (test, compile, etc.) which is no problem for me. I

The fastest way to teach rebar selectable config sets is to join the
discussion in the linked tickets (and write patch(es)) :).

> think that including none of the dependecies is not better or worse
> as including all of them. I wanted to make sure that everything the
> user may need is in place without configuration. Therefore, the
> rebar_escript_plugin even searches the configured lib_dirs for
> non-system applications to include. In my opinion, if you want to
> avoid, e.g. proper, from being packaged along, you should generate
> the escript from a release specification.

%% list of apps
{escript_incl_apps, [app1, app2]}.

%% include release spec apps (might require asking reltool/relx)
{escript_incl_apps, release_apps}.

%% include all apps configured via rebar.config
{escript_incl_apps, project_apps}.

> (3) Sorry, this is not yet documented in the README. In order to
> unpack your 'priv' content the plugin needs to have its own main/1
> function called first. However, the default runner (starting all
> needed applications and block) is only used if you don't specify
> your own main function. If the module with the name of the escript
> exports a 'main/1' function the plugin will call it (from the main
> process) after priv extraction with the original arguments (as rebar
> would). When writing the runner I had services like the serve_it
> example application in mind. I assumed we all write proper OTP
> applications ;-) therefore the simple default runner.

We can and should promote one good way of doing things, but we cannot
assume all projects are like that. That said, we can probably make
this work reliably.