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.
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.
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.
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?
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)
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.
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.
We have System.otp_release() # => "26" but not System.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 what mix hex.info does for example, but the first step would be to have OTP expose this.
Adding :minimum_otp_release/:otp_version to 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.
Rebar3 also does it this way and this therefore seems to be the accepted way to do so:
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.
)
