[erlang-questions] [ANN] rebar_escript_plugin

[Tobias Schlager]

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.

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 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.

(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.

(4) This is the tricky part of the plugin and I agree with you it would be awesome if escript and erl_prim_loader would do the right thing automagically. Additionally, escript has no possibility to register signal handlers to run when someone terminates the process, e.g. CTRL-C. Therefore, the plugin (miss-)uses the heart process and proxies the HEART_COMMAND to schedule cleanup of its temporary directory... I couldn't come up with a nicer solution. Signal or at least cleanup handlers would also be a cool OTP contribution.

Thanks again for taking the time to share your thoughts.

Regards
Tobias

________________________________________
Von: Tuncer Ayaz [tuncer.ayaz@REDACTED]
Gesendet: Mittwoch, 3. September 2014 13:15
An: Tobias Schlager
Cc: Erlang
Betreff: Re: [erlang-questions] [ANN] rebar_escript_plugin

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