Read Elixir version from mix.exs file

[Stratus3D]

In addition to the .exenv-version file, asdf-elixir should also be able to read the Elixir version out of a mix.exs file in the current directory.

See this related issue for kiex: taylor/kiex#54

[dbernheisel]

I like this!

Couple questions:

• I'm not sure how this will account for different OTP versions that Elixir could be compiled with. Do you see something that could help find this? I don't see anything in mix.exs that specifies the OTP version, unless folks just add it. For example:

  def project() do
    [
      app: :my_app,
      version: File.read!("VERSION") |> String.trim(),
      elixir: "~> 1.5",
      otp: "21"
    ]
  end

• Let's say that 1.5.2 is the latest Elixir version, and mix.exs specifies elixir: "~> 1.5". At the time asdf install is ran, does it fetch the latest 1.5.x version or earliest? If latest, and then later 1.5.3 releases, should asdf install require 1.5.3? Would asdf say the "specified" version is not yet installed, or would it be satisfied? I figure if folks want a specific version of Elixir for their app, they could specify elixir: "1.5.2" instead. Should there be a .tool-versions.lock generated until explicitly told to upgrade? (I figure this is a bigger question for asdf).

[Eiji7]

@dbernheisel

• I'm not sure how this will account for different OTP versions that Elixir could be compiled with. Do you see something that could help find this? I don't see anything in mix.exs that specifies the OTP version, unless folks just add it. For example:

In Elixir we do not depend on specific Erlang version. However in some rare cases we may write code that uses a new Erlang's API. Therefore the safest option is to pick latest supported version. For more information, see:
https://hexdocs.pm/elixir/compatibility-and-deprecations.html

• Let's say that 1.5.2 is the latest Elixir version, and mix.exs specifies elixir: "~> 1.5". At the time asdf install is ran, does it fetch the latest 1.5.x version or earliest? If latest, and then later 1.5.3 releases, should asdf install require 1.5.3? Would asdf say the "specified" version is not yet installed, or would it be satisfied? I figure if folks want a specific version of Elixir for their app, they could specify elixir: "1.5.2" instead. Should there be a .tool-versions.lock generated until explicitly told to upgrade? (I figure this is a bigger question for asdf).

This is a theory vs practice. In theory 3rd number is used only for patches i.e. there should not be any new features, so in theory any version would work. However the safest option is again the latest one for specific pattern. There is one more thing … "~> 1.5" matches versions in range 1.5.0-2.0.0 (left inclusive and right exclusive). If we want to follow Elixir then we should install version not prior 1.5.0 and prior 2.0.0 (if any), but preferably we should pick latest 1.x version in this case. That's said using newer Elixir version in practice means at least dealing with soft and hard deprecation messages.

The problem with mix.exs is that you need to have a working Elixir installation to read it. The regular expressions are no use as for example someone may write:

defmodule MyApp.MixProject do
  @app_version "1.0.0"
  @elixir_version "~> 1.5"

  def project() do
    [
      app: :my_app,
      elixir: @elixir_version,
      version: @app_version
    ]
  end
end

If we want to solve this issue "once and good" then we need to:

1. Create a simple CLI app written in Elixir
2. Generate a release with ERTS and a mix application included (to read mix.exs file easily)
3. Optionally setup CI to automate this (or just upload those files somewhere)
4. Inside a Bash script we should download the binary with curl/wget (it's not really new thing that asdf plugin requires it) and call it to read the mix.exs file

Using a compatibility table we can also generate a list of supported Erlang versions or just generate a .tool-versions file.

[Stratus3D]

I opened this feature request, but I feel the complexity around this somewhat negates my desire to actually implement this. Great idea in theory, complicated to implement correctly and in a way that isn't surprising to users. Users haven't complained about having to put the version in the .tool-versions file so I'm not sure it's worth doing.