Re: Elixir 1.12.0, OTP 24.0, port updates & older OTP version deprecations

Hi,

On Thu, 27 May 2021, Dave Cottlehuber wrote:

> 1. add a lang/elixir-devel version.
> 
>         Revision URI: https://reviews.freebsd.org/D30490
> 
> This would allow users to always have the latest elixir release installed.
> NB many elixir libraries today don't handle all the deprecations in 1.12/OTP24.

This will certainly happen when rolling your own releases based on 
Elixir. Rather than creating a -devel port (which is not actually 
-devel at this point) maybe we could end up with an elixir-runtimeXX, 
bound to its own erlang-runtime, to that people can install it in 
parallel and use it for release packaging.
 
> 2. bump lang/elixir to 1.11.x branch.
> 
> https://reviews.freebsd.org/D28092 already does this, but...
> 
> this requires "making rabbitmq work" which Jimmy seems to know what's
> needed.

I gave it a try and it seems that it's just a basic change in the 
version check.

The main issue is that RabbitMQ should be brought up to date, but I 
haven't been using it for a while so I'm afraid I would inflict some 
serious damage to actual users :)

I think RabbitMQ uses Elixir for the CLI, so it could be patched to 
get it from the -runtime port above.

> 4. proposal to drop most of the elixir-* dependent ports
> 
> I'm not convinced most of these ports are actually worth having in
> ports at all, who would install any of these, and not use mix & hex
> packages directly?

I'd say drop most of erlang-* too. It seemed like a nice idea at the 
time, but the overhead is massive and it's easy to get conflicts. 

Large applications should be able to be built as Erlang releases, but 
maybe this can't be done in all cases so a few ports could remain. In 
the worst case one could grab the dependencies from hex.pm, but the 
process is very fragile and that's why rebar3 is still a few revisions 
late :|

> This would be in line with e.g. golang dependencies. Unless there is
> some particularly useful NIF/C dependencies we should consider dropping
> them.

I have a few custom ones and they build just fine with rebar or mix, 
so that shouldn't be an issue (other than getting CFLAGS right as 
usual).

> 5. proposal to drop OTP20 & erlang-riak

+1

Not sure if anything is holding up Erlang, maybe it could go up to 23?

Thanks a lot for all the good work! \o/

-- 
jimmy