Wrapping your Elixir app in a Burrito

Probably not an original title but here I am talking about turning an Elixir command-line tool I built into a native executable.

When I needed to learn Elixir (that we’re using in AgendaScope) I picked a project I’d been thinking about for some time: a tool for building interactive fiction. I liked the problem particularly because it would exercise a lot of ground but be quite self contained.

It was a great learning experience and, along the way, I a couple of tools I’m quite proud of: a parser combinator library, Ergo, and a library for representing multiple files as a single contiguous file, LogicalFile.

So now I have this tool that is actually pretty close to being usable and I start thinking about how other people might test it out and that’s where my use of Elixir strikes me as not so good.

You see Elixir has the notion of an escript which is a script that embeds Elixir so a user doesn’t need Elixir installed. But Elixir depends upon Erlang and does need the Erlang runtime system (ERTS) installed. For the kind of people I am targeting that felt awkward.

Along comes Burrito which creates a native binary for macOS, Linux, and Windows. The binary that automatically installs ERTS for the platform and hides all that stuff in the background.

Some things that I struggled with:

1. I didn’t spend enough time looking at the example app. Don’t be like me.
2. When you create the releases() function in mix.exs you need to actually call it from your project() function as releases: releases() this does not magically happen. Without this mix release will function but Burrito won’t do anything. If you’re unfamiliar with mix release as I was you might see what it does as “working” and be quite confused.
3. In your releases() function the key (which is example_cli_app in their example) should be the app key from your project() function.
4. If you use MIX_ENV=prod mix release then beware that the binary will not include updated code no matter how much you mix compile unless you also bump the project version.
5. On macOS the cached deployment is in ~/Library/Application Support/.tinfoil which makes no real sense to me and was pretty hard to find. If you don’t fall foul of (4) above this may not matter to you.

All in all most of my issues were lack of observation on my part. The tool works (although I confess I haven’t been able to test the cross-platform binaries) and is a boon to anyone building command-line tools who wants to keep using their favourite language.

Without Burrito I’d probably be learning Zig or Nim right now.