Gleam's usage of Erlang libs

[erlend-axelsson]

I'm trying to create a minimal Docker image for running gleam applications, which in my case means I'm basing it on scratch and copying over just the essentials. And that leads me to this question, which Erlang libraries does the compiled erlang-shipment rely on and which can I safely remove?

Basing it on erlang:26.2.5.0-alpine I get these libraries from /usr/local/lib/erlang/lib and I'd like to remove the unnecessary ones.

drwxr-xr-x    5 root     root        1.2M    May  6 19:05 asn1-5.2.2
drwxr-xr-x    6 root     root        1.7M    May  6 19:05 common_test-1.26.2
drwxr-xr-x    4 root     root        2.9M    May  6 19:05 compiler-8.4.3
drwxr-xr-x    4 root     root        340.0K  May  6 19:05 crypto-5.4.2
drwxr-xr-x    5 root     root        660.0K  May  6 19:05 debugger-5.3.4
drwxr-xr-x    4 root     root        1.5M    May  6 19:05 dialyzer-5.1.3
drwxr-xr-x    6 root     root        1.2M    May  6 19:05 diameter-2.3.2
drwxr-xr-x    7 root     root        596.0K  May  6 19:05 edoc-1.2.1
drwxr-xr-x    5 root     root        196.0K  May  6 19:05 eldap-1.2.12
drwxr-xr-x    4 root     root        736.0K  May  6 19:05 erl_docgen-1.5.2
drwxr-xr-x    6 root     root        1.7M    May  6 19:05 erl_interface-5.5.1
drwxr-xr-x    3 root     root        628.0K  May  6 19:05 erts-14.2.5
drwxr-xr-x    5 root     root        236.0K  May  6 19:05 et-1.7
drwxr-xr-x    5 root     root        268.0K  May  6 19:05 eunit-2.9
drwxr-xr-x    3 root     root        132.0K  May  6 19:05 ftp-1.2.1
drwxr-xr-x    6 root     root        996.0K  May  6 19:05 inets-9.1
drwxr-xr-x    5 root     root        2.8M    May  6 19:05 kernel-9.2.4
drwxr-xr-x    6 root     root        6.2M    May  6 19:05 megaco-4.5
drwxr-xr-x    5 root     root        1.2M    May  6 19:05 mnesia-4.23.1
drwxr-xr-x    6 root     root        1.3M    May  6 19:05 observer-2.15.1
drwxr-xr-x    6 root     root        144.0K  May  6 19:05 odbc-2.14.2
drwxr-xr-x    5 root     root        184.0K  May  6 19:05 os_mon-2.9.1
drwxr-xr-x    4 root     root        284.0K  May  6 19:05 parsetools-2.5
drwxr-xr-x    6 root     root        1.5M    May  6 19:05 public_key-1.15.1
drwxr-xr-x    4 root     root        496.0K  May  6 19:05 reltool-1.0
drwxr-xr-x    5 root     root        340.0K  May  6 19:05 runtime_tools-2.0.1
drwxr-xr-x    4 root     root        420.0K  May  6 19:05 sasl-4.2.1
drwxr-xr-x    8 root     root        3.4M    May  6 19:05 snmp-5.15
drwxr-xr-x    5 root     root        1.3M    May  6 19:05 ssh-5.1.4
drwxr-xr-x    4 root     root        2.2M    May  6 19:05 ssl-11.1.4
drwxr-xr-x    5 root     root        5.4M    May  6 19:05 stdlib-5.2.3
drwxr-xr-x    4 root     root        432.0K  May  6 19:05 syntax_tools-3.1
drwxr-xr-x    4 root     root        152.0K  May  6 19:05 tftp-1.1.1
drwxr-xr-x    5 root     root        668.0K  May  6 19:05 tools-3.6
drwxr-xr-x    5 root     root        5.8M    May  6 19:05 wx-2.4.1
drwxr-xr-x    5 root     root        2.0M    May  6 19:05 xmerl-1.3.34

[lpil]

It will depend on what ones the programmer uses in their application. It is not something you can do in a generic container image.

wx is a GUI framework so you can likely remove that.

[erlend-axelsson]

Ok, thanks. Is there any way besides trial and error I could check what the standard library / official packages use?
I figured third party dependencies might bring in whatever, but I was hoping I could establish a "baseline" and then explicitly bring in the extra ones when needed.

[lpil]

They are the Erlang standard libraries. You would need to inspect your application to determine which modules it uses.

The xref program could be helpful but there's no trivial way to do this and it cannot be done for a generic container image as an application could use any of them.

[erlend-axelsson]

Thank you again for the quick response I'll have to read up on xref, but I think I might have miscommunicated the purpose of this image 😅.

I'm not intending to create a generic image for applications, rather what I'm trying to achieve is to create something I can use to build a rootfs for a Unikraft unikernel.
Something similar to unikraft.org/python:3.12 which then would be used like Python Flask SQLite.

Though having though a bit more about it I think it might be a better option for me to just leave the libs for the moment and assemble something that works, then start pruning extra stuff until something breaks.