How to write an Elixir terminal app with `mix release` instead of escript?

Background

I have an elixir app that is a terminal application. After discussions in this forum, it was strongly recommended to me to that I do not use escript and use mix release instead:

So, naturally, now I want to build an elixir app, it can be as simple as an hello world app, that uses mix releases, in terminal.

Problem

The issue here is that all the information I found thus far, all the tutorials (even the ones in this forum) use escript, the exact tool I want to avoid. Therefore I dont know how to build a simple terminal app that when invoked with a parameter returns hello world.

Questions

  • Does anyone know how to build an Elixir app with mix releases that upon execution with a command returns hello world?
  • Is it even possible to have this without escript?
2 Likes

There’s a really crummy way to do this (just replace (MyApplication.start/1) with IO.puts("hello world") and strike out that supervisor stuff, but I really would like to know if there’s a better way to deliver script-ey things as a packaged release (possibly with dependencies, like ExAws or Jason, for example)

To be clear, if you want to build a command line app, then by all means, use escript. But if you want a long running system that you are going to deploy in a server somewhere, then releases are a better fit.

Releases are not going to give you a convenient command line API though. The best you can do is to assemble a release and run commands like start, rpc, and eval.

6 Likes

I think the operational challenge is how to deliver a “script”, as in, not a server; not persistent; one-shot only. to something that doesn’t necessarily have elixir on it already. Maybe you don’t have the credentials to install elixir, for example, but you’d like to do something that takes advantage of Elixir’s concurrency (and maybe also uses a 3rd party lib). I think the releases’ eval is the only thing that fits this bill, is that correct?

Yes and no. Releases need to be build specifically for the architecture of the target system (OS, C ABI, 
). This usually doesn’t play nice with how people want to build their terminal applications and is one of the reasons people often suggest to use something else than a beam language to build those.

1 Like

Right, I forgot about system matching
 Yeah I get to be lazy where I work due to Linux monoculture.

Even that won‘t help much. Different versions of the same distro are often not compatible with each other.

2 Likes