Background
I am doing a personal project and as a deliverable I create a script using MIX_ENV=prod mix escript.build.
My program is in this small script so when I want to use it I can just run it via ./my_script --args.
It works great for the most part, but I had some questions so I started digging - which is when i found this:
(https://hexdocs.pm/mix/master/Mix.Tasks.Escript.Build.html)
Escripts should be used as a mechanism to share scripts between developers and not as a deployment mechanism. For running live systems, consider using mix run or building releases.
Why?
My application is a terminal application, so using escript looked like an obvious choice. Why should I use mxi release instead of having a script file?
Both need erlang on the machine they are going to run on, and mix release actually needs to compile in a machine with the same architecture and OS system of the machine that is going to execute the file (a luxury I cannot afford for now).
Could someone explain me what are the main drawbacks of using escript?
1 Like
escripts does not support accessing content in priv directories. That rules out serving static files, running migrations, etc, right out of the box. They also don’t provide the same flexibility as Mix tasks, which provide different entry points and command line options. And at the end of the day, both Mix and Escripts are inferior when it comes to system configuration compared to releases.
So can you use escripts? Sure, you can, but they are inferior in almost every way compared to other options, so I don’t see the point of using them besides one-off scripts.
7 Likes
A release doesn’t require neither erlang nor elixir to be installed on the target machine as long as you either pack ERTS (the default) or the machine has ERTS accessible, it does require that the release be assembled on the same target architecture indeed and to assemble the release you do need erlang and elixir, but you can do that with docker easily mimicking wtv targets you wish.
2 Likes
That requires me to have docker and to do mix release in a docker container. This inevitably adds complexity I would pretty much like to avoid and I am not sure how it even fits with the rest of my pipeline.
While I do agree this is a solution worth exploring, I would personally like a release process like with other technologies where you can define the OS and architecture when building the release.
Imagine not having to use docker nor any additional tools and just run mix realease --os=linux --arch=amd64. (
since @josevalim is now reading this 
)
This however, is outside the scope of this post (nor do I know if this is even possible to begin with) and you have provided a viable solution.
Thank you for the answer it is clear now !
Maybe it worth to mention about it in the mix escript.build docs? I had the same question and reached this post after reading the docs.
1 Like
Technically you can. The escript api takes an archive of files where you can include priv directories. This is how rebar3 works and rebar3 escriptize supports this as an option, escript_incl_extra.
Also, one thing not mention that releases provide over escripts is the ability to bundle ERTS. You can not create a self-contained escript but must have Erlang installed on the system you are deploying to.
3 Likes
This would be simple to implement if restricted to only fetching OTP for that architecture. The issue is what is done for NIFs, ports, etc that are in the project? That is outside the scope of a release task and would require all the different compiler tasks, like zigler, rustler, and general makefiles and rebar3’s pc plugin have a common interface for assigning the architecture and each to support cross compiling.
But I’d also point out that for many people it doesn’t require docker/vm – except for those who have a hard requirement on deploying local code directly to a target and don’t run on the same env as the target – because usually CI is involved before deploying were the release can be built and either directly deployed or pushed to some storage to be deployed later.
2 Likes
Oh, one last thing. If you don’t have to compile the code for your escript on the same arch as where you are running it then you don’t for a release either.
Releases do not have to contain ERTS, so a user who is fine with having the Erlang runtime installed on the target host only has to compile any other potential native code for that host. There must be no native code in the project so no need to build the release on a particular architecture and set of system libraries, simply leave out ERTS.
All that to say, nothing about a release is unique in requiring compilation on the target host that doesn’t also apply to running the project any other way because you do not have to bundle ERTS into the release.
3 Likes
A mix release that doesn’t include the Erlang VM will have the exact same properties as an escript. You only need the target compilation if you are bundling the VM and if you need to bundle NIFs (not supported by escripts IIRC).
I mean, we also include them, but IIRC it is not easy to read them. You would need to use an special API for so?
2 Likes
Don’t think so. Can just read them like regular files with regular paths (path just has to include the name of the escript).
2 Likes
