Based on what I’m reading in the mixRelease function, the Nix version of Erlang should be removed if it detects that ERTS is bundled with the release. However, this is not happening (for me?)
reading the mixRelease code and comments, it says that it removes runtime references in the output erlang files, not Nix store references to erlang. This makes sense right, since we have them in the Nix store, looking for erlang at runtime would cause issues, or at least is useless. The nix store -q -references command returns the store path references of the derivation, i.e. build time dependencies.
A Mix release is self-contained, so the output of the command is not runtime deps here. In fact if you look at result/erts-15.2/bin, you’ll see compiled erlang binaries (erl, erlc, etc) i.e. the binaries you need at runtime.
How would I make use of this release without including the erlang build-time dependency?
When I make use of it like this, I end up with erlang in the container’s nix store:
container.nix
{
pkgs,
nix2container,
simius,
}:
# TODO: figure out why simius gets rebuilt even when it isn't touched
let
minimalLocales = pkgs.glibcLocales.override {
allLocales = false;
locales = [ "en_US.UTF-8/UTF-8" ];
};
in
nix2container.buildImage {
name = "simius";
config = {
env = [
"LOCALE_ARCHIVE=${minimalLocales}/lib/locale/locale-archive"
"LANG=en_US.UTF-8"
"LANGUAGE=en_US:en"
"LC_ALL=en_US.UTF-8"
];
entrypoint = [ "${simius}/bin/simius" ];
cmd = [ "start" ];
};
layers = [
(nix2container.buildLayer {
# a list of derivations copied to the image root directory
copyToRoot = [
(pkgs.buildEnv {
name = "busybox";
paths = with pkgs; [
# a `sh` is required
busybox # includes `sh` and many other utils without wasting much space
];
pathsToLink = [ "/bin" ];
})
];
})
];
}
If I understand you correctly, I would need to only include the runtime dependencies in the container, but this also includes the build time dependencies?
$ podman run -it --rm --entrypoint=/bin/sh simius:05vg4yh3ffcjpf9jzgcx100mv7crkcfl
/ # ls /nix/store/ | grep erlang
186j3w6wqlqqc8c2sljxhw72ffvc5h0p-erlang-27.2
Back when I played with mixRelease, there was a comment in some generated script, that was an absolute path to the erlang compiler used to build the project.
I was under the impression that I contributed a patch to to the builder that would remove this reference, though I can not find it in the history, though I can see that there are mesures taken to remove any references.
So here we need to better debug what is holding the reference.
So please build your mixRelease result, and not some docker container, and use nix why-depends on it to see why it still refers to that erlang path.
Do you happen to know to what extent this can actually be a problem?
# This reduces closure size, but can lead to some hard to understand runtime
# errors, so use with caution. See e.g.
# https://github.com/whitfin/cachex/issues/205
# https://framagit.org/framasoft/mobilizon/-/issues/1169
stripDebug ? false,