OTP version mismatch

[michaelstalker]

When I use the elixir:1.6.1-alpine image, there's a mismatch between the OTP version on the OS and the OTP version for Elixir.

RUN elixir -v

outputs

Erlang/OTP 20 [erts-9.2] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false]
Elixir 1.6.1 (compiled with OTP 19)

I think this is causing some intermittent Sentry compilation errors like getsentry/sentry-elixir#232.

[sdwolfz]

See the discussion in #35 on why that is the case.

In short, the precompiled packages we use are compiled with erlang 19.
Maybe we should change the dockerfiles to use builds from here, specific to the erlang version: https://github.com/hexpm/bob#elixir-builds

[c0b]

https://github.com/hexpm/bob#elixir-builds

I agree that looks like a better option; the situation now is better than 2015 when this project started, when the recommended way was to use the Precompiled.zip and the Precompiled.zip had only one compiled OTP version

now when the hexpm build service has https://repo.hex.pm/builds/elixir/v1.6.1-otp-20.zip it looks like better than to use the default
https://github.com/elixir-lang/elixir/releases/download/v1.6.1/Precompiled.zip (which is compiled from the lowest supported OTP version, from the Compatibility matrix, it's built from OTP 19)
The only concern is how stable / reliable / official is the hexpm build service? could someone get it mentioned from the official Elixir site? https://elixir-lang.org/install.html

[michaelstalker]

Another option would be to make install clean your own Elixir build in the Alpine and slim images. It looks like that's what's happening in the normal Dockerfile.

[michaelstalker]

A co-worker and I just created a Docker image that uses the erlang:20-alpine image, and compiles Elixir with OTP 20. Here's the Dockerfile. Would it be helpful if I created a PR for docker-elixir with this Dockerfile? If you're thinking about using Bob instead of compiling Elixir yourselves, my approach probably isn't a great long-term solution to getting OTP versions to match up. On the other hand, if you'd feel more comfortable using the official .tar.gz Elixir artifact, my Dockerfile uses it.

[c0b]

if you track some earlier discussions in this issue tracker, I was intended to do that way, download the source tarball and compile and docker build, like what I did in the erlang images,
(the Erlang community's difference is there's no official binary release, Erlang maintainers do release each source tarball only, so each Erlang is indeed built from source tarball; but the Elixir community does have both source tarball and Precompiled.zip as binary release);
then at that time either @josevalim or another Elixir maintainer said there should be no benefits to build from source code, since we do have the official binary release, hence we're picking up each binary release (the Precompiled.zip) for each new Elixir release, since early days of this repo;

Right now the "OTP version mismatch" is indeed a problem, it's because using a latest Erlang image (built from latest version Erlang source) + latest Elixir binary release, but the binary Precompiled.zip was built with a previous version of OTP, for wider OTP compatibility reasons, which is causing the mismatch problem;

Should we now switch back to use the building from source tarball solution? I'd like to keep this open for longer time discussion.

[josevalim]

Elixir always guarantees it works with the minimum supported version, so in theory, using the precompiled version should be fine.

@michaelstalker, did you try running the Sentry suite with Erlang 19 and the same precompiled Elixir version and see if the issue happens as well? I cannot think of anything in the compiler that would justify the behaviour you are seeing.

[michaelstalker]

@josevalim I haven't tried compiling the Sentry library with Erlang 19 and the precompiled Elixir. That's a good idea. I was never able to get a good trace to see which files the compiler couldn't find. However, one file that triggered the failure only contained references to Mix modules and modules built into the Elixir language, which strikes me as really odd, because like Mix and Elixir should both have been loaded already in order for compilation to even start for my project. That makes me think it's possible that I'm misdiagnosing the problem.

[c0b]

see #63 #70 for some latest effort to use hexpm/bob version of precompiled elixir. comments are welcome