Add action for macOS

[paulo-ferraz-oliveira]

No description provided.

[wojtekmach]

This is tricky because while we have OTP images for Linux and Windows, we don't have such for macOS.

We hope to address it in erlang/otp#4487.

In the meantime, I think we could wrap Homebrew. This workflow:

runs-on: macos-10.5
steps:
  - uses: erlef/setup-beam@v1
    with:
      otp-version: 23

would under the hood call:

$ brew install erlang@23

At this moment we can run:

• $ brew install erlang (OTP 24)
• $ brew install erlang@23
• $ brew install erlang@22
• $ brew install erlang@21

See: https://formulae.brew.sh/formula/erlang

We can't install particular versions, e.g. 23.3.0, and these versions are moving targets, but I think that's OK.

If we're to move forward with this homebrew based solution, it begs the question why not let the users do it themselves, just have them call brew install ... themselves. I think having this in the action would allow nice things like:

strategy:
  fail-fast: false
  matrix:
    os: [ubuntu-latest, macos-latest, windows-latest]
    otp: [24]
    include:
      - os: ubuntu-latest
        otp-version: 23
runs-on: ${{matrix.os}}
steps:
  - uses: erlef/setup-beam@v1
    with:
      otp-version: ${{matrix.otp}}

Furthermore, the action could cache homebrew stuff which would be a nice win for users too.

WDYT?

[starbelly]

I think that's a good stop-gap solution yes. The limitations are unappealing, but some times something is better than nothing. I'd like to say this should be impetus for the work we've discussed here and there for doing github action builds devoid of Bob, but that needs to be discussed further and I don't think would be any quick solution for it. Then again, maybe starting off such setup with merely mac os builds of erlang is perfect way to start 🤔

I think if we did wedge it in this way, it should be clearly highlighted that we do not support brew, problems you encounter with brew, or use of brew outside of what the action does (which should be opaque). To be clear : "You are free to use brew as it's installed ,but we do not support issues you run into that are not directly related to this action"

In the end, I'm in favor of it so long as it's quicker than setting up a github action based build system.

[jlouis]

Just thinking out loud here:

would using https://github.com/kerl/kerl get us to where we want? It can build any Erlang version we want, more or less. So as long as we can provide an image of some kind to start from, builds should be fairly easy to set up and get going. But I don't know if github actions allows us to make images like that for macos.

As for the necessary dependencies, we can probably pull those via homebrew. Which suggests a path:

• Get a homebrew version to work, first.
• Add kerl/kerl on top of that.

[paulo-ferraz-oliveira]

I guess the main issue we need to solve is "Where to get pre-compiled stuff from?". As @wojtekmach suggested brew might do the trick (haven't tested how long it would take, though). kerl, on the other hand, involves compilation, which is time-consuming (a LOT!) - unless you know fo some functionality I don't. If we could get those builds (even if with kerl) somewhere online, using it shouldn't be a big problem. Also, I think @starbelly will raise this issue in one of EEF's Build and Packaging meetings, to see if the OTP team could make the images available (they already do, for Windows, and I'm not sure if there's more Windows users than macOS, Erlang-wise).

[wojtekmach]

"Where to get pre-compiled stuff from?"

Exactly!

I took another stab at upstreaming image building to the OTP team, keeps the fingers crossed! erlang/otp#5036

[paulo-ferraz-oliveira]

That's great @wojtekmach, thanks. After that I'd be glad to merge the macOS in the action.

[jlouis]

Yeah, something like kerl would need us to have a place to store the intermediaries. I was of the impression that some of this works off of docker images, but I might have been mistaken.

[starbelly]

Yeah, something like kerl would need us to have a place to store the intermediaries. I was of the impression that some of this works off of docker images, but I might have been mistaken.

There's some flexibility in not depending on docker images solely. Namely for the case of self hosted runners where you might not be using docker at all (i.e., bare metal, spinning up VMs, etc.).

On a side note and related to this issue I'm terribly curious to see what's being cooked up here by @wojtekmach .

@wojtekmach I saw on twitter where you said this could perhaps be used by this action. Could you elaborate?

[wojtekmach]

Regarding kerl, I think it is a great tool. As was said, it can build all sorts of OTP versions even across different OSes.

That being said, in my opinion setup-beam should not rely on kerl directly or indirectly.

I think setup-beam should use official OTP builds as much as possible. It already does for Windows. If erlang/otp#5036 lands, we'll make setup-beam use those too. And if OTP has official builds for Linux, I think setup-beam should eventually use those too. This means the Hex team could retire https://github.com/hexpm/bob#erlang-builds which we are keen to. If there were official OTP builds for Linux there most likely would not be a need for Hex to have those builds. Again, kerl really excels at building various OTP versions on various OSes but if we can use official OTP builds, let's do that!

A problem with official OTP images is there is a limited amount of them. For example, there are no official images for OTP 20 for Windows. If erlang/otp#5036 lands, I imagine we'll start building them on OTP 25, maybe OTP 24.1, or something. I think that is actually OK that we won't have all versions of OTP ever for Windows and macOS. I think it is totally reasonable for folks to maybe test their stuff on a couple of versions of OTP for Linux and just one OTP version on Windows/macOS. I don't think a huge build matrix, N OTP * M OS is needed the vast majority of time. Maybe someone needs huge build matrix and maybe setup-beam should accommodate that use case but I personally don't see the need for that.
The fact that there are only so many official OTP builds is going to be less of an issue as the time goes on. Say, 3 years from now, people shouldn't be really use 3+ yr old OTP versions.

@wojtekmach I saw on twitter where you said this could perhaps be used by this action. Could you elaborate?

I think you might be referring to this https://twitter.com/wojtekmach/status/1413614275042676742 so just to clarify, I meant that erlang/otp#5036 should be used by setup-beam. elixir-run could be used but I don't think it should. Not least because it is extremely experimental at the moment. :) I don't have plans for elixir-run to support a wide variety of Erlang+Elixir versions, something that setup-beam would like to have. If there is a new elixir-run version, and that is a big if :), it would use the latest Erlang version + latest Elixir version at that particular point in time, that's it, no backfilling.

[wojtekmach]

Well, there's another way that elixir-run could be used here but not quite ready to talk about it yet. :)

[Fudoshiki]

erlang/otp#5036 merged

[wojtekmach]

I opened the final PR which would publish the macOS builds on OTP GitHub releases: erlang/otp#5723

[paulo-ferraz-oliveira]

@wojtekmach, I've seen you do stuff on OTP PRs but I'm not sure what's the status there. Are macOS builds available, at this moment? Thanks.

[wojtekmach]

OTP CI is creating Mac builds. You can see them here:

(https://github.com/erlang/otp/actions/runs/2774278710)

These builds are not uploaded to any release though and so are likely only available for a limited time period. erlang/otp#5723 is about automatically uploading these builds to releases but is waiting on a decision to move forward.

[paulo-ferraz-oliveira]

Cool stuff. Thanks for the update. (when stuff's finished, if you don't want/have time/interest in updating this GHA, I might give it a go...)

[nathany-copia]

This would be useful for libraries doing matrix builds to easily ensure they work across common development platforms.