bitwalker/exrm — pull request #37 by alco (2014-07-09 01:40:38+00:00)
Title: Proof-of-concept for command-line app release

_This shoud not be merged!_

So this is something to start the conversation. You can see this working in [miniweb](https://github.com/alco/miniweb) ([relevent commit](https://github.com/alco/miniweb/commit/744b0ff84ff81239c3c0721e8b2bf88da6f9d87a)). Clone the project and do the following:
```
$ mix deps.get
$ MIX_ENV=rel mix release
$ rel/miniweb/bin/miniweb cli
```

Points of interest:

* The `cli` command I added to the boot script is almost identical to `foreground`. The only differences are: 1) no shell is started; 2) a module is supplied to run with the command-line arguments; 3) `:erlang.halt` is called in the end (this may need to be changed).

* Disabling embedded mode makes the startup time of the release to be the same as the dev version.

---

The way I have implemented it, the CLI aspect is coupled with the rest of the release mechanics. But it could be made optional and the `cli` task should really be extracted into a separate script. In that case, it will only be generated if `mix.exs` contains the `release: [main_module: ...]` option.

To make this possible, there needs to be a common baseline script that sets up parameters like configs, boot scripts and whatnot. This baseline script can then be sourced into both `boot` and `cli` scripts.

---

Another idea I had in mind: imagine an app that has a server and a command-line components, a-la docker. The server can be packaged into a release as usual, and the command-line part can be implemented as an escript that communicates with the server via RPC. The caveat is how to make the escript use the Erlang version from the release.

This actually works out of the box:
```
$ mix escriptize
# produces `uweb` executable

$ lib/miniweb/erts-6.0/bin/escript uweb --version
μWeb 0.1.0
```
but it should also be possible for the `uweb` script to locate the Erlang version from the release in some way. I haven't thought this through, but just mentioned as an idea I had.

Similarly, if we had a hypothetical GUI app, the meaty part including all of the app logic could work as a normal release, and the part that simply starts the GUI application could be wrapped in an escript that communicates with the started release node via RPC. I'll take a look at Wings 3D later and see how it bundles Erlang.

---

To sum up, here are the questions I have:
* should `exrm` support the ability to release CLI apps?
* does the idea of making it possible via an additional script (as an alternative to the main boot script) sound good?
* would it be possible to make `exrm` aware of escript to be able to generate a script that knows where to look for the release?

That's all I have for now.