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.
josevalim
Creator of Elixir
jozuas
I wanted to add another example of this happening from today:
I have Elixir 1.15.7 with Erlang 25.3.2.7, I added oidcc 3.1.0 to mix.exs and found out in runtime that oidcc only supports OTP26 and beyond by running into :base64.encode/2 is undefined or private.
0
maennchen
I believe having a standardized field & warning for the required OTP version in the mix project/0 would be beneficial.
It at least communicates the problem to the user and there is also a standardized place to manually look for the versions a library supports.
Also checking the requirement in the hex resolution would be awesome, but I don’t believe that this must be implemented for the rest to be useful.
(Happy to provide an Elixir PR for that 
)
0
wojtekmach
Hex Core Team
There is a couple of problems:
- We have
System.otp_release() # => "26"but notSystem.otp_version() #=> "26.1.2"and the reason is the latter is not exposed by OTP. There are hacks to get this version out, you can see whatmix hex.infodoes for example, but the first step would be to have OTP expose this. - Adding
:minimum_otp_release/:otp_versionto mix.exs that works like :elixir, i.e. does not participate in resolution, should be fairly straightforward. Adding it in a way that participates in resolution is a rather big undertaking.
mix.exs is executable so something everyone can do today is:
if System.otp_release < "26" do
IO.puts "this package requires OTP 26. Install foo v0.2.0 that works with prior OTP versions"
raise "incorrect OTP"
end
defmodule Foo.MixProject do
and the benefit is the error message can be as succinct or as verbose as you want it to be. In that sense it’s better than when provided by the build tool because you have full control what extra information to include.
2
maennchen
While this feels hacky, this is the officially proposed way to read the version:
Rebar3 also does it this way and this therefore seems to be the accepted way to do so:
https://github.com/erlang/rebar3/blob/7a27a26c11470617898b9a3c80451d1cea1c4361/apps/rebar/src/rebar_utils.erl#L415
This should allow us to create System.otp_version/0 if we desire to have that function.
I’m aware that this is possible, but this seems like a hack to me. If everybody does it like this, there’s no standardized approach which means that we won’t be able to handle those errors in a uniform way. (e.g. Editor Language Servers, statistical analysis of libraries & their requirements on Hex etc.)
Implementing only the first part (without resolution) seems to be an easy implementation and I think it would be beneficial. Exposing System.otp_version/0 would also be great since that is something I had to work around before.
0