On statically link of everything, this is something i will probably explore in the coming months. In case you want to exchange ideas.
I would be happy to collaborate! Might be a good idea to open an issue on the Distillery tracker where we can talk through ideas and experiment a bit, there are various other members of the community watching the tracker, including those who contribute to not only Distillery but Elixir and Erlang, and I tend to pay closer attention to it myself (for obvious reasons), but a thread dedicated to it here may be more visible, so I could see having the discussion in both places as beneficial.
I would especially like providing a build tooling that use Distillery but provides static linking through musl and build a tarball with all needed dependencies (OpenSSL comes to mind), so that we have a “fully ready” app outputted.
Yeah this is more or less what I had in mind, but I have not tried an actual implementation of this to see how well it works in practice, and what the pain points are. I just found the docs that indicate how to statically link NIFs not in the standard library (as well as any libs they depend on), but I wonder if there are other issues hiding there (is there any special support required to ensure such NIFs support being statically linked?). If NIFs are statically linked, then that means each application which uses NIFs requires a unique build of ERTS, and with how long that takes to build, that may be really painful. I don’t know if it’s possible to blend static and dynamic linking to resolve that, but even if it was, I think you sacrifice all the benefits of a static build if you still need all the system libraries available for dynamically linked NIFs, so my intuition tells me this is a dead end simply because of the build overhead required, but I would be interested to see the results of some experiments to validate that assumption.
But i think that should be pluggable in that system, so that people can choose easily. I have ideas and begun playing with it. It will at least ease the deployment, but will probably not totally solve it. But it should also make cross compilation easier…
I would agree that this should definitely be an “optional” path, as there are clearly much simpler ways to operate assuming you have some basic build infrastructure already in place, so this is the kind of thing you would opt into if you want to avoid all of that and build and deploy straight from your development machine (or perhaps use existing build infra that doesn’t match your target system, and so needs cross-compilation).
About mounting a filesystem image : i am not sure yet. There are stuff we could do and i have ideas. An Illumos Zone environment would make things easier, we could produce a Zone image… We could also probably provide a Nix-env that work well. Guix could also work.
Oh I know for sure it works, and as you have pointed out, one could use zones, LXC, etc., to provide platform-specific outputs; the question from my point of view is “who builds those plugins?”. For example, while I would love to work in an environment with Illumos, I don’t, so I don’t have the operational expertise to build a solution for zones which makes the most of their capabilities. I could research and develop that expertise, but having to do that for all possible environments is not practical. So what I would like to bulid are really solid base primitives which fulfills those requirements I mentioned previously (“easy to use” and “easy to learn”), and let the community develop plugins which build on those primitives in a way that is seamless (i.e. add dependency A providing the plugin for zones, put a line in your configuration to use that plugin, and everything just works). To some extent this has already happened, there are a number of plugins for Distillery to produce things like .rpm or .deb packages, and there are higher level tools like Edeliver and Bootleg which also build on Distillery’s output, but the underlying pain points (being unable to build from any machine and deploy to any target, configuration discrepancies, no Mix, etc.) bubble up to those plugins and tools, so we need to solve for those at the lowest level, and only then will higher level tools be free of having to hack around those issues.
For containers, it is a bit harder. But it could be possible to side load something like Oracle does with GitHub - oracle/crashcart: CrashCart: sideload binaries into a running container … or do something like micro container, but this is, i think, more an output plugin problem than a solution for everyone.
Right, there are already tools for building container images from a release, so I think this is more or less a “solved” problem, or at least not a pain point for the majority of the community (and speaking from experience, working with containers with what we have today is already pretty painless, just using Distillery and raw Docker commands, so I think the majority of issues lie elsewhere).