Specifying minimal Erlang version in mix.exs

Questions / Help
, ,
#1

Is it still not possible to specify Erlang compatibility in mix.exs?

Erlang/OTP is a dependency of Elixir, so it is an indirect dependency of any mix projects, but it may be a direct dependency too. mix.exs should be able to convey that and mix should be able to resolve dependencies handling this too.

As a practical example, :crypto.hmac/3 no longer exists in OTP 24, one must use :crypto.mac/4 which is OTP 22+

If a package maintainer wants to use :crypto.mac/4, the only easy choice is to require the shiny new Elixir 1.12, because Elixir 1.11 is compatible with OTP 21

Ideally one could say: compatible with Elixir >= 1.7 but OTP >= 22.

6 Likes
#2

Interesting request. Totally doable.

It will not compile if it does not meet the :otp dependency requirement.

$ mix
** (Mix) You're trying to run :otp_dependency on Erlang/OTP 24.0.0 but it has declared in its mix.exs file it supports only Erlang/OTP ~> 24.1
4 Likes
#3

Correct, it is still not supported because we want to avoid adding multiple dimensions for system dependencies. So in this sense it would be preferable to either supporting v1.7 and all OTP versions by checking which crypto function is available (that’s what we did in plug_crypto) or bumping to v1.12.

However, if occurrences like this keep happening, then we should probably be more pragmatic and allow the OTP dependency.

5 Likes
#4

You can always have runtime/compile time check that will pick the best available option.

1 Like
#5

Smells like a compat library that I wanted to write for at least a year.

#6

Thanks for the link to this workaround. I’d say that if we get to a failed compilation, we still lost though.

The goal is that mix deps.get resolves to the correct version of package, not that it resolves to the wrong version, that compilation fails, and that the user must figure out why, then figure out manually what version is actually compatible, hardcode the version requirement and then reinstall.

1 Like
#7

Thanks for the response, although I do not see how erlang is in a different dimension, from the point of view of a package manifest.

I will check what was done for plug_crypto

#8

My solution does not deal with package dependencies. It only checks --as the title of your post says-- that the installed OTP version meets the requirements, in the exact same way it checks for the Elixir version required.
If your requirement is Elixir v1.12, but you are running Elixir v1.11, the compilation will fail, and I wouldn’t see it as a loss, it is a gain because your app is not designed to run under a lower version of Elixir.

How would you propose your solution to work? To have conditional dependencies based on the available OTP version?

#9

I guess you can make a dummy erlang package with rebar.config that have:

{minimum_otp_vsn, "22"}.

then add this package as one mix dependency?

1 Like
#10

My solution is that hex packages could declare which OTP version they are compatible with and that mix deps.get takes that into account to figure out which versions to get.

If package Example has version 1.0 compatible with Elixir >= 1.4 but uses :crypto.hmac/3, they could make incompatible changes to the code to use the new :crypto.mac/4 and release 1.0.2 compatible with Elixir >= 1.7 and OTP >= 22. mix deps.get can use that information to retrieve the correct package depending on the version of Elixir and OTP that is in use, and insure that there is no incompatiblity / compilation error.

The only other acceptable alternative in my book requires more work on the part of the maintainer to release a package that maintains compatibility with all versions of OTP.

I lack the experience to know how much of a burden that is, but that solution has the advantage of expressing the situation as it actually is, as well as giving more options to maintainers to minimize their burden. Not allowing that is fighting reality.

(edited to remove a step that didn’t add anything)

1 Like
#11

Interesting. If that works, then even more reason to support explicitly what can already be supported implicitly.

#12

It doesn’t work on dependency resolution. It just emits a warning (or raise) if you don’t have a matching version. If this behaviour is enough for you, then you can check for the OTP release in your mix.exs.

1 Like