nimbus-eth2 1.5.5 (new formula)

[riptl]

• 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?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

nimbus-eth2 is an implementation of the Eth2 beacon chain in Nim. Eth2 is a series of ongoing upgrades to the Ethereum cryptocurrency to fix the high energy usage of the network.

This PR is part of a series of new formulas. There exist a few implementations of Eth2, most notably Prysm (Go), Nimbus-Eth2 (Nim), Lighthouse (Rust) #91984 and Teku (Java) #91986. All of these clients are well maintained, implement the same protocol and have mostly the same ergonomics. I aim to enroll all of them in Homebrew.

[riptl]

This Makefile pulls in an entire Nim compiler toolchain, instead of using one provided by Homebrew. This should be fixed upstream before creating a formula.

[zah]

Can you clarify why is this considered a problem? I can imagine various motives:

1. All downloads of a recipe should be explicitly described through some homebrew-specific API, so they can be verified (against a checksum) and the recipe can be potentially executed in a network-isolated/offline environment.

2. All intermediate build files should be easy to clean up after the build and the Nim compiler dependency doesn't meet this criteria.

3. Building your compiler toolchain as part of your build is just considered a sub-optimal approach (i.e. an excessive waste of time).

I'd like to help in resolving the perceived issues, but first I need to understand your concerns better. I doubt Nimbus is the first project that builds a custom tool required only during the build process and I would argue that Nimbus doesn't depend on Nim at run-time, so we don't need to introduce a dependency on Nim in the Homebrew recipe.

[riptl]

@zah Thank you for taking a look at this. The acceptance criteria are here: https://docs.brew.sh/Acceptable-Formulae

Specifically

We don’t like install scripts that download unversioned things

If I understand correctly, the nimbus_build_system is built from master via a Git submodule.

A Homebrew maintainer is more qualified to comment on this

[zah]

Through the use of git submodules, we precisely pin the version of the Nim compiler being used as part of our build. We take reproducible builds very seriously, so this applies to all other components as well.

[riptl]

@SMillerDev would you mind taking a look at this? (context: pulling in the compiler via Git submodule)

[carlocab]

That sounds like it's not exactly in line with this: https://docs.brew.sh/Acceptable-Formulae#stuff-that-requires-vendored-versions-of-homebrew-formulae

[zah]

@carlocab, clearly, the security of Nimbus (a software dealing with finances in the form of cryptocurrencies) is of paramount importance. We, the team behind Nimbus, care very strongly about keeping our dependencies up-to-date with regard to security vulnerabilities and we pin the version of every component used during the build exactly in order to control precisely what goes into the shipped binaries. Here is a relevant except from our docs:

We've designed the build process to be reproducible. In practice, this means that anyone can verify that these exact binaries were produced from the corresponding source code commits. For more about the philosophy and importance of this feature see reproducible-builds.org.

[SMillerDev]

I don't think that warrants an exception to our rules.

Please consider hosting it in a personal tap, which is very easy to do: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap

[riptl]

According to upstream

any Nim version other than the one we're shipping (which, on rare occasions, might be a temporary fork) is unsupported and should not be used by packagers.
The Nim compiler breaks backwards compatibility often, so you cannot treat it as a C compiler.

The Nim compiler version is pretty closely coupled to the Nimbus project itself. So we can't use the nim package as a build dependency. The build script instead fetches the compiler toolchain from an external source.

[zah]

@terorie, shall we re-open this? As discussed in the sub-thread, the concern of pulling a precise version of Nim during the build process shouldn't be a problem.

[riptl]

@zah Sounds good, I've also invited you as a collaborator if you need to push directly to this PR: https://github.com/terorie/homebrew-core/invitations

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.