Re: Why the difference between lang/elixir and lang/elixir-devel? (also: elixir-devel doesn't support mix release)

From: Pat Maddox <>
Date: Thu, 26 May 2022 04:03:24 UTC
On 17 May 2022, at 5:52, Dave Cottlehuber wrote:

> On Tue, 10 May 2022, at 04:12, Pat Maddox wrote:
>> I had been working on a patch to lang/elixir-devel to support mix
>> releases, per the problem I shared in
>> When working on it, I saw that lang/elixir doesn’t have the problem 
>> -
>> it doesn’t patch `elixir` to “hard-wire” the OTP release. So I 
>> can
>> just depend on lang/elixir instead.
>> I had assumed that lang/elixir-devel just provided a more up-to-date
>> version of elixir, to get access to a newer elixir while still using
>> quarterly ports.
>> That appears not to be the case. Two key differences I note are:
>> 1. lang/elixir depends on lang/erlang, whereas lang/elixir-devel 
>> depends
>> on lang/erlang-runtime*
>> 2. lang/elixir builds elixir as-is, whereas lang/elixir-devel patches
>> the `elixir` script to “hard-wire” the OTP release.
>> What is the intent of the lang/elixir-devel port?
> Hi Pat
> TLDR log an issue against lang/elixir-devel for fixing mix release &
> tracking this. The OTP21-OTP22 transition was a major breakage point
> for OTP stdlib and stuff needed to be hard wired to work reliably.


> -devel flavoured ports are the leading edge of ports dev. As a ports
> committer it allows me to easily switch a subsidiary port (like
> net/rabbitmq or phoenix) over for testing, as I choose, & back again.
> As a user, it allows me to test my apps against the very latest.

Okay that makes sense. I’ve taken a closer look at the two Makefiles 
and see that they are indeed similar - the key difference being that 
elixir-devel depends on an erlang runtime rather than lang/erlang, and 
that it patches the elixir script.

I will experiment with removing the post-patch hard-wire from 
elixir-devel. I believe when I did that, elixir failed to run because 
there was no erl on the path. lang/erlang puts erl on the path, but 
erlang-runtime* do not. If I’m remembering correctly.