gleam+rebar3+erlang_ls: depend on erlang@26

[paulo-ferraz-oliveira]

We're pining rebar3 to erlang@26 at this moment (because of gleam), since we're getting ready for erlang@27, not supported by the former.

Reasoning: gleam doesn't work with OTP 27 yet (?) - I'm not certain of this, at this moment, because the ecosystem moves fast, but I'll keep my eye out for updates.

---

Further considerations

It's not that rebar3 itself needs to depend on erlang@26 (it should build fine with erlang, or erlang@27). It's that gleam depends on rebar3 and thus we have a mismatch in dependencies which CI complains about. And then we need to update erlang_ls lest we get another mismatch.

---

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• gleam: Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• rebar3: Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• erlang_ls: Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• gleam: Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• rebar3: Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• erlang_ls: Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• gleam: Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?
• rebar3: Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?
• erlang_ls: Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[github-actions]

🤖 An automated task has requested bottles to be published to this PR.

[paulo-ferraz-oliveira]

What's this about? (for my education for potential future pull requests)

[carlocab]

It means that pre-existing gleam installs should now be considered outdated, which avoids their getting broken when erlang gets upgraded to Erlang 27 (because pre-existing gleam installs are still configured to use the erlang formula and not erlang@26).

[paulo-ferraz-oliveira]

Got it.

[paulo-ferraz-oliveira]

@carlocab, I wanna tackle an issue I think rebar3 (Erlang's official build tool) has, which is the following... Erlang/OTP guarantees bytecode compatibility for 3 major versions, which means that once 27 is out there's no guarantee that code from 24 will work. rebar3 maintains the same policy, which means that it is distributed as being compiled with <erlang_cur> - 2. In Homebrew it's actually compiled with the latest Erlang (not right now, but in normal circumstances it would be compiled with 27). I'm not sure of what the best strategy here is, but to increase compatibility it should be compiled with <erlang_cur> - 2.

In other words if you try to use rebar3 compiled with Erlang 27 with an Erlang 24 install (which is very possible given developers have multiple Erlang versions locally) it won't work.

Do you think this is resolvable by script? e.g. fetching as a dependency erlang@<cur-2> instead of a specific Erlang/OTP? Or should this be moved by hand?

(I can open an issue, otherwise, for follow-up)

[carlocab]

Do you think this is resolvable by script? e.g. fetching as a dependency erlang@<cur-2> instead of a specific Erlang/OTP? Or should this be moved by hand?

A mix of both. See #191485.