Re: Elixir 1.12.0, OTP 24.0, port updates & older OTP version deprecations
Date: Mon, 31 May 2021 11:04:45 UTC
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