Optionally install Eqwalizer / ELP

[robertoaloi]

eqwalizer is a type checker for Erlang.

ELP or Erlang Language Platform has a powerful CLI that can be used as a linter to detect (and autofix) unused macros, unused headers and other bad smells in code.

See, for example, usages in RabbitMQ and brod.

It would be great to have both eqwalizer and ELP as optional installations for the setup-beam action, as this would enable users to be able to perform validation for their code base during CI with minimal effort.

Binary executables are provided for both Linux and Mac. Installation from source is documented here.

[paulo-ferraz-oliveira]

👋 I'm not sure the action should support this 😄, but I'm listening. We're basically an installer for pre-compiled elements that support code development, like the compilers and runtimes. Having this here would, maybe, open the door to start having rebar3_lint, rebar3_format/erlfmt, rebar3_hank, etc. since these are all lib.s that support development (even if not pre-compiled and Erlang/Elixir -ish). Fwiw, for example, we also don't install dialyxir as a means to ease CI on Elixir projects. Maybe I'm missing something in your intent, but I feel this can be easily covered with an example Gist on how to do it (?)

[robertoaloi]

Hi! ELP and eqwalizer have both a non-trivial setup due to the fact they require, respectively, a Rust and Scala runtime. Having a centralized action would highly simplify their adoption in CI and serve as documentation, too.

Of course one could write a simple gist or tutorial, but than we'd have a discoverability problem. Users would need to be aware of the gist/tutorial and where to find it. Whenever the gist changes, users would need update their copies.

Conversely, a GitHub action is a composible, re-usable components that users can simply reference in their CI, without worrying about internals. It is more easily maintainable and it can be updated with a single version bump.

I agree we may not want to overload the setup-beam action itself with all possible dev tools in the ecosystem, though. Maybe having a separate action for those could be a good compromise?

For other components, I wouldn't mind having auxiliary actions if those tools require a complex installation procedure (say, other than installing a package).

[paulo-ferraz-oliveira]

Maybe having a separate action for those could be a good compromise?

I believe so, and the same for Eqwalizer / ELP. What you're getting from setup-beam is a thin layer around "grab this version of this tool and install it", but focused on BEAM and higher-level languages. And I'd be Ok to participate in implementation or help out if required.

[robertoaloi]

Some help on this would be terrific! I have never contributed an action before but I can help with the ELP parts, what's the best way to make this happen?

[paulo-ferraz-oliveira]

By separate action I mean a separate repo. Is that what you were thinking, too? I think we could start by having a name for the action, and a repo. (@starbelly would be able to create a repo., I can't - or maybe even you, I see you in the org.s members, but don't know if you're an admin). Then I could create a small skeleton for it, and you'd fill in the blanks. 😄

[robertoaloi]

erlef/setup-elp sounds like the most obvious one. A skeleton would help!

[robertoaloi]

Also yes, it looks like I can create repos O_o
Not sure where the super-power comes from.

[paulo-ferraz-oliveira]

Not sure where the super-power comes from.

You're a member of the erlef org. and possibly also an admin. 😄

---

Once you create the repo. I can upload a minimal action to it (I created something yesterday, already); I think I just need to be an external collaborator (to go fast), or otherwise I need to pull request. And then we can discuss more details there, like the interface and where the assets are fetched from, etc.

[robertoaloi]

I'm apparently a member of one of the teams. But I don't want to abuse my powers since I don't know if that's intentional. Let's wait until @starbelly gives a go-ahead.

[paulo-ferraz-oliveira]

In the meantime, Roberto, could you tell me:

• what are the expected inputs? Maybe it's just the versions of the tools? And are they semver or something else?
• where to obtain the tools from (and what architectures are available)?
• what outputs would you expect the action to make available?

[starbelly]

I like this idea 😄 We just need it to run through build-and-packaging to see what the general thought is. At the start, we made a decision that we didn't want to have too many projects under the umbrella of the erlef as people didn't want this to end up like the apache foundation (where projects go to die). I don't think that's the case here what so ever, but it would be remiss of me not run it by the working group first.

[yordis]

It could be added under https://github.com/erlef/gh-actions/tree/main/stable, which was the intent of the repo.

Before moving some typical setups, I am trying to prove a few things across multiple Elixir (sorry, I only have a little Erlang experience in CI); all I ask is that you be as generic as possible but tackle the 80/20 situation. When in doubt, small steps could be combined to achieve higher abstractions.

- use: erlef/gh-actions/stable/[email protected]

[robertoaloi]

That would be perfect. We could also publish it in a private repo (@paulo-ferraz-oliveira's ?) for the time being and eventually transfer it to the erlef once it goes through the build-and-package working group.

What are the expected inputs? Maybe it's just the versions of the tools? And are they semver or something else?

We can probably start with the ELP version only. Eqwalizer is packaged in there. The version has the format YYYY-MM-DD or YYYY-MM-DD_N if there are multiple releases per day. No semantic versioning.

Where to obtain the tools from (and what architectures are available)?

Binaries are published as release assets. Example here.

We currently provide binaries for Linux (x86_64 and aarch64) and Mac x64_64. There's also a Mac aarch64 but I think the eqwalizer artifact is still for x64_64 in there (we should fix that, but I believe there was no runner available for that platform). All artifacts are currently available for OTP 25 and OTP 26.

We probably need to depend on setup-graalvm to be able to run Eqwalizer.

All the magic happens here.
Installation instructions from binary are also available here.

What outputs would you expect the action to make available?

I would expect the elp CLI to be available in the pipeline so that commands such as elp eqwalize and elp parse-elp can be used to perform, respectively, type checking and linting (similar to rebar3 dialyzer and rebar3 elvis.

[starbelly]

@robertoaloi I think people think this is a good idea 😄 I can go ahead and make a repo, are you still wanting to go with setup-elp? Just let me know

[robertoaloi]

@starbelly setup-elp would be perfect!

[starbelly]

@robertoaloi done. I kicked it off as private, feel free to change at your digression 😄

[robertoaloi]

@starbelly Thanks!

@paulo-ferraz-oliveira is the one who will probably publish the first skeleton. Do you have access to it?

[paulo-ferraz-oliveira]

Do you have access to it?

Seems not 😢

I'll start in my profile, as Roberto suggested, then move it somewhere. If erlef won't have it, maybe jelly-beam will. 😄

I'll also close this discussion and start new issues there.

[paulo-ferraz-oliveira]

Moved to the reference mentioned above.