Propose use for `asdf`, `setup-beam`, `homebrew`, `Nix`, etc.

[paulo-ferraz-oliveira]

Even if it doesn't end up there, at the moment, it'll be a good exercise to measure difficulty in integrating.

• [ ] asdf
• [ ] setup-beam
• [ ] homebrew
• [ ] nix
• [ ] beamup
• [ ] kerl
• [ ] official Docker images (?)

[paulo-ferraz-oliveira]

Maybe when this is discussed we should break it up into several issues.

[michallepicki]

I created a macos plugin at https://github.com/michallepicki/asdf-erlang-prebuilt-macos (and I have Ubuntu plugins at https://github.com/michallepicki?tab=repositories&q=asdf-erlang ) but the upstream tracking issue is https://github.com/asdf-vm/asdf-erlang/issues/165

[paulo-ferraz-oliveira]

👋

Would it make sense to merge the asdf-erlang-prebuilt-macos plugin into the existing one? It'd benefit faster adoption (?)

If the issue already mentions it, sorry, I didn't read it in depth.

[garazdawi]

Hello! I was thinking that maybe the best place would be to patch kerl, as that seems to be the tool that most other build managers use under the hood? Or do we want to keep kerl as a build from source tool?

[wojtekmach]

Here we have builds for OTP master/maint/maint-{release}, is kerl able to build those too? If it can (or it's easy to make it so) then this is moot, but otherwise it could be where we draw the line, i.e. it's not part of kerl?

[garazdawi]

kerl can build any sha from any git otp repo, so yes it can build Erlang/OTP master/maint/maint-X.

[paulo-ferraz-oliveira]

I don't think the goals of the two projects are the same. Some ideas... kerl allows:

1. for configuration options, which these builds don't (they're pre-determined)
2. building docs (if I remember correctly, it was proposed here, but postponed as a decision)
3. for POSIX-compatible multi-platform/multi-OS (which we'd probably need to adapt this project be)
4. compiling debug versions of the VM
5. you to chose whatever repo you want to build from
6. managing multiple versions in the same OS (something asdf requires under-the-hood...)

And now that I think about it I don't know how we'd pass options to asdf if it used pre-compiled elements (maybe that's being discussed in the linked issues, above).

I think the easiest-to-adapt-to use cases, here, are:

• setup-beam
• Homebrew
• Nix
• official Docker images

But I'm all ears in how we can make all these tools converge.

[garazdawi]

I agree that the goal of kerl is a superset of otp_builds, but for the most common usage, could it not fetch prebuilt images instead? If you just do kerl build-install 27.1 without setting any other options, can't it download a prebuilt image instead of building it?

Anyway, it was only a thought. I'm probably in a minority that use kerl directly instead of going via some other tool build on top of it :)

[wojtekmach]

If kerl downloads prebuilt images by default then https://github.com/asdf-vm/asdf-erlang/issues/165 is automatically solved which would be a win. If not kerl, asdf-erlang should download prebuilt by default in my opinion.

[LostKobrakai]

Mise does have an experimental native plugin for erlang as well, which seems to be built on top of kerl for now as well: https://mise.jdx.dev/plugins.html#core-plugins

[wojtekmach]

Oh, good to know! I think they started with using asdf-erlang under the hood. +1 for downloading prebuilt in kerl then. :)

[paulo-ferraz-oliveira]

If kerl downloads prebuilt images by default then https://github.com/asdf-vm/asdf-erlang/issues/165 is automatically solved which would be a win. If not kerl, asdf-erlang should download prebuilt by default in my opinion.

Whatever the case is I think this discussion would fit better in the kerl repository directly. I'm a contributor, but not the only one.

I agree there's room, also given @garazdawi's comment, to use pre-built where possible, but kerl is not macOS -specific, so it'd be interesting to, at least, think about how we'd make the downloads consistent from different sources (maybe otp_builds will be the place where all those pre-build images could be fetched from (?)).

As I stated in the asdf discussion (a few minutes ago), though, whether it's opt-out or opt-in, it needs to be clear to the consumer. At the moment, though, for kerl, I think the use case is not exactly the same as asdf, but I can image an option KERL_PREFER_PRECOMPILED to handle it.

So:

1. it could fit there, as an option (or the default), as long as it's possible to keep current behavior
2. if asdf keeps using kerl whatever it provides is win-win for both systems, because asdf would use pre-compiled in some occasions and configured/compiled in others

[wojtekmach]

I believe we can close this issue given:

asdf

https://github.com/asdf-vm/asdf-erlang/issues/165

setup-beam

https://github.com/erlef/setup-beam/issues/54

homebrew

I don't think it makes sense, I believe the whole point of brew is to dynamically link openssl, wxwidgets, etc.

nix

I don't think it makes sense, I believe they are building everything from scratch themselves.

beamup

Already using it.

kerl

There was a discussion here and in https://github.com/asdf-vm/asdf-erlang/issues/165.

official Docker images (?)

At the moment we only support macOS, perhaps once we start rolling out Linux builds we'd reconsider this.

[LostKobrakai]

Mise just merged changes to allow overriding their core plugin with another method like https://github.com/michallepicki/asdf-erlang-prebuilt-macos

https://mise.jdx.dev/dev-tools/aliases.html

[paulo-ferraz-oliveira]

Sure, we can close it.

[wojtekmach]

Whatever the case is I think this discussion would fit better in the kerl repository directly. I'm a contributor, but not the only one.

Yeah, good idea.

[paulo-ferraz-oliveira]

https://github.com/kerl/kerl/issues/550