Compiler warnings with Elixir 1.16

[kaifeldhoff]

Environment

Erlang/OTP 26 [erts-14.2.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit:ns]
Elixir 1.16.2 (compiled with Erlang/OTP 26)

"dialyxir": {:hex, :dialyxir, "1.4.3", ....}

Current behavior

Compilation-warnings are thrown caused Erlex:

warning: in order to compile .yrl files, you must add "compilers: [:yecc] ++ Mix.compilers()" to the "def project" section of erlex's mix.exs
  (mix 1.16.2) lib/mix/tasks/compile.yecc.ex:70: Mix.Tasks.Compile.Yecc.preload/1
  (mix 1.16.2) lib/mix/compilers/erlang.ex:66: Mix.Compilers.Erlang.compile/6
  (mix 1.16.2) lib/mix/task.ex:478: anonymous fn/3 in Mix.Task.run_task/5
  (mix 1.16.2) lib/mix/tasks/compile.all.ex:124: Mix.Tasks.Compile.All.run_compiler/2
  (mix 1.16.2) lib/mix/tasks/compile.all.ex:104: Mix.Tasks.Compile.All.compile/4
  (mix 1.16.2) lib/mix/tasks/compile.all.ex:93: Mix.Tasks.Compile.All.with_logger_app/2

warning: in order to compile .xrl files, you must add "compilers: [:leex] ++ Mix.compilers()" to the "def project" section of erlex's mix.exs
  (mix 1.16.2) lib/mix/tasks/compile.leex.ex:69: Mix.Tasks.Compile.Leex.preload/1
  (mix 1.16.2) lib/mix/compilers/erlang.ex:66: Mix.Compilers.Erlang.compile/6
  (mix 1.16.2) lib/mix/task.ex:478: anonymous fn/3 in Mix.Task.run_task/5
  (mix 1.16.2) lib/mix/tasks/compile.all.ex:124: Mix.Tasks.Compile.All.run_compiler/2
  (mix 1.16.2) lib/mix/tasks/compile.all.ex:104: Mix.Tasks.Compile.All.compile/4
  (mix 1.16.2) lib/mix/tasks/compile.all.ex:93: Mix.Tasks.Compile.All.with_logger_app/2

My project has no Dialyzer-issues, so there is no evidence, that these warnings affect the functionality of Dialyzer/dialyxir.

Expected behavior

No severe compilation warnings.

I can only assume that these warnings are an issue for dialyxir. They started to occur after switching Elixir version from 1.15.7 to 1.16.2.

Unfortunately @asummers (maintainer of Erlex) has been inactive for years. A PR for this issue already existed since January. There is a rumor that he might even have passed away in 2022, hopefully this is simply not true.

How can we tackle this?

Many thanks!

[christhekeele]

I've reached out to both the maintainer and support@hex.pm to see if we can transfer ownership of the package to a maintained fork, in the event that @asummers is unable to or uninterested in continuing to keep working on erlex.

[jeremyjh]

@christhekeele Any word back on this? Another option would be for me to bring it back into the dialyxir repo and namespace. It started in this repo, but we wanted it to be available for other use cases as well is why erlex exists as a separate project, but if Andrew is no longer maintaining it then I think we have to here.

[jeremyjh]

Yes, Andrew is gone. Wow, it is very shocking and saddening to me.

https://www.gffh.com/andrew-david-summers/

[christhekeele]

@jeremyjh no word, I'm afraid.

[kaifeldhoff]

@jeremyjh, so it is true. We've found his name on other pages but were never 100% sure. That is truly a sad story.

The discussion about all this started in https://elixirforum.com/t/erlex-dialyxir-dependenty-does-not-support-elixir-1-16-any-suggestions/62714?u=kai_feldhoff. (Seems like this is only visible for forum-members, so you should have access)
Here it's also mentioned that elixir-lsp is using erlex. They already forked and fixed the elixir 1.16 issue. And there are additional forks. Looks like the work of @asummers found more use-cases. So from my point of view it might not be the best option to put erlex back into dialyxir.

As we didn't know the history of dialyxir and that erlex has been a part of it, we just began to think about keeping @asummers-project alive. And that lead to the need for a new maintainer. @christhekeele was the first to take the initiative, with nobody else so far. As he mentioned he already reached out to hex.pm to start the 30 days counter that is needed to switch ownership for the project. A good idea from my point of view. I've thought about creating a looking-for-maintainer forum-thread to get things rolling further. Just in case to give the numberless volunteers a chance ;) .

But as I now know the deep relationship between dialyxir and erlex please tell me your thoughts about all this. Should we stay on this road or do you have other ideas or opinions?

[jeremyjh]

dialyxir is the only dependency listed in hex.pm. elixir-lsp vendors it but they have to since they are vendoring dialyxir, I don't think they use it directly. Issues in erlex mostly get reported here, so I'm of two minds about it. If @christhekeele wants to maintain erlex and will have control of the hex.pm package within the next couple of weeks I'm totally fine just letting that play out.

[kaifeldhoff]

dialyxir is the only dependency listed in hex.pm. elixir-lsp vendors it but they have to since they are vendoring dialyxir, I don't think they use it directly. Issues in erlex mostly get reported here

That is an important point. Now I understand that integrating erlex into dialyxir is also a good option. But what happens with the hex-project of erlex? Could you please join the forum-thread? With the help of the community we hopefully get to the best decision.

[christhekeele]

If @christhekeele wants to maintain erlex and will have control of the hex.pm package within the next couple of weeks I'm totally fine just letting that play out.

👍

---

dialyxir is the only dependency listed in hex.pm. Issues in erlex mostly get reported here.

Now I understand that integrating erlex into dialyxir is also a good option. But what happens with the hex-project of erlex?

As you point out, the future of the package is separate from dialyxir's decision to fold the code into itself. I'd still update the package with pending/new community contributions, and eventually consider a warning-based deprecation path to sunsetting the package if non-dialyxir usecases and users do not emerge.

[christhekeele]

No update from hex.pm, but I've spent some time today preparing a fork here.

• The only changes to lib and src are applied from merged open PRs in the original.
• The rest are tooling changes to move CI over to GH Actions, and fully test against all supported OS/OTP/Elixir versions of the project so development can proceed confidently that nobody's experience will break.