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.

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

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.

There is a couple of problems:

1. 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.
2. 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.

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