Vendor in kerl and Homebrew

[starbelly]

Similar #3, we should also consider vendoring in kerl. Once again, let's keep third-party code quantified. This also helps with stability as well.

Edit: when we pull stuff in (via curl, wget or git) verify that the origin is Ok by comparing SHA checksums or whatever is available.

[paulo-ferraz-oliveira]

This should be easy, I guess. What I'd dislike is for us to start reinventing the wheel if stuff exists out there, because our time and energy is limited and maintaining something like this (which attempts to build Erlang in macOS over several versions) will already be cumbersome (we all know the amount of issues that can potentially arrive from the simple build process itself).

[paulo-ferraz-oliveira]

My goal here, is to go through KERL_DEBUG's output and check what makes sense to use. It'll probably not be much, but we'll see...

[starbelly]

To note, it's kind of hard to re-invent the wheel here IMHO. I'm not opposed to using kerl, kerl solves a specific set of problems. As an example, it allows me to build and install and manage many different versions of erlang/otp in my environment. We don't have a need for that, so it's literally just a ./configure --flag ... job for us.

You may have some other thoughts, that I have not considered though.

[paulo-ferraz-oliveira]

It's not "just" configuration flags, but as stated earlier, I have a goal for this. Kerl does stuff like:

• create the proper folders,
• pass in the configuration options,
• guess stuff from the environment,
• help us list the releases (which we're using to know what to build),
• install,
• etc.

But I do agree we can distil it and use what we need, though I'm pretty sure it won't be a one-liner 😄