Discussion: Should we drop support for binary distributions?

[Profpatsch]

@robinbb writes:

Should we continue to try to support the Haskell toolchain in rules_haskell via binary distributions?

Opinion:
Support the Haskell toolchain via bindists seems like a difficult thing to do well. The most reliable way to obtain a working Haskell toolchain on a given distro is to use the distro's version of it, if available. Perhaps equally reliable is using rules_nixpkgs. Next most reliable is probably to compile from source both ghc and the dependencies that it requires (ncurses for libtinfo, GMP for libgmp, etc.); but this is a lot of work and a lot of compiling. Least likely to work seems to be what we are doing now, which is to choose a binary distribution from haskell.org, ignore the dependencies, and try to make install it into a Bazel-cache location.

This is a useful discussion to have because it addresses what is at the heart of the -pie-vs-no-pie flag bugs filed against rules_haskell. The problem is that the toolchain code tries to download a bindist made for Debian9 and install it. This isn't even guaranteed to work on Debian9, the way it is coded, now.

Making this strategy work would require that the rules_haskell repo contain high quality build code for ghc, ncurses, gmp, and one or two other packages. But, there is no ecosystem of build code for Bazel-building code which is normally installed via an OS package manager. So, we would have to invent it. And set up CI for it. Across a variety of OS's. That is, if we want to ensure that it works well. Does rules_haskell want to be in that business?

[hazelweakly]

Perhaps equally reliable is using rules_nixpkgs

The first immediate concern that strikes out to me is "what does this mean for windows builds". The second is, of course, that all of the bazel and nix integration currently require nix installed globally, which isn't great (it very much complicates git clone && cd && one_build_command && go grab coffee which is certainly something to aspire to, especially if a project regularly onboards new people)

[robinbb]

I agree that git clone <x> && cd <x> && one_build_command is to be aspired to. Already, however, there is a problem with dependencies. In what language is one_build_command written? What version of that language? To which versions of which other software utilities does it call out? If one_build_command is to be bazel test, then which version of Bazel is required? Do any .bazelrc.local modifications have to be made in order to work with the rest of your machine's context? Already there is a dependency management problem for which a solution is desirable.

Perhaps the problem is the degree to which the bindists are not acceptable as-is for GHC and its dependencies. Is this perhaps an upstream problem?

I don't know the answers, but I'm pretty sure the answer is not for Bazel rules to take on the responsibilities of package managers and operating system distros for building large dependency trees of software packages.

[aherrmann]

In short, I think we should support a "host" toolchain as described in #1320, as well as an improved bindist toolchain as described in #1393 .

---

We currently implement two ways to provide a GHC toolchain in rules_haskell

• haskell_register_ghc_nixpkgs imports GHC from Nix via rules_nixpkgs.
• haskell_register_ghc_bindists downloads a GHC bindist and runs ./configure && make && make install during configuration.

Nix is the best option to obtain a hermetic GHC toolchain and avoid implicit system dependencies. However, this option is only available if Nix is available. In particular it is not an option on Windows, but we also have users on Linux or MacOS that can't or prefer not to use Nix. Meaning we need some mechanism outside of Nix to provide GHC.

As @robinbb identifies correctly the current bindist mechanism has a few issues regarding hermeticity. The ./configure && make && make install is executed during configuration outside of Bazel's build sandbox, meaning it will use whichever cc toolchain it finds on PATH. It also assumes that certain libraries are installed globally at the correct versions, e.g. libtinfo.

#1393 proposes to improve the current bindist mechanism by performing the ./configure && make && make install in a regular build step rather than at configure time to make this more hermetic. This would also make it possible to inject Bazel managed versions of libraries such as libtinfo if needed.

#1320 proposes a "host" toolchain where we just use whichever GHC is installed globally. I think this is also what @robinbb is proposing with

The most reliable way to obtain a working Haskell toolchain on a given distro is to use the distro's version of it, if available.

I think both approaches are useful and we'd want to support both. The "host" toolchain can for example be convenient on CI setups where GHC is installed in a separate step, e.g. a GitHub action, or Docker image. The approach of downloading a bindist is useful for projects that don't use Nix but still want to have a single command build and ensure that all developers use the same compiler version.

---

Next most reliable is probably to compile from source both ghc and the dependencies that it requires

I would not recommend building GHC from source in Bazel. Building GHC from source can be hard to setup and can take hours. The bindists try to provide a middle ground by doing most of the build for you and leaving only a small configure step do be done on installation site (only required on Unix). Note, Unix bindists that don't require the configure steps are discussed here. In #1393 we also discuss dedicated prebuilt GHC bindists for rules_haskell.

This is a useful discussion to have because it addresses what is at the heart of the -pie-vs-no-pie flag bugs filed against rules_haskell. The problem is that the toolchain code tries to download a bindist made for Debian9 and install it. This isn't even guaranteed to work on Debian9, the way it is coded, now.

To clarify, the -no-pie issue is not due the the bindist being built for Debian9. Whether the C compiler supports -no-pie is determined in the ./configure step when you install the bindist on your machine and stored in the settings file. The problem is that passing -pgmc, as we do in rules_haskell, makes GHC ignore the settings file. See here.

An issue that is caused by the bindist being built on Debian9 in that case is that it depends on certain versions of system libraries such as libtinfo. In principle we could allow users to point the bindist rule to a bindist built for a different Linux distribution. With #1393 we could also allow to inject Bazel managed versions of these libraries.

Making this strategy work would require that the rules_haskell repo contain high quality build code for ghc, ncurses, gmp, and one or two other packages. But, there is no ecosystem of build code for Bazel-building code which is normally installed via an OS package manager. So, we would have to invent it. And set up CI for it. Across a variety of OS's. That is, if we want to ensure that it works well. Does rules_haskell want to be in that business?

I don't think we need to go that far. The bindist rule provides a compromise between being able to pin the GHC version while accepting implicit dependencies on other more common system libraries. Comparable features exist in rules_go or rules_nodejs, or stack outside of Bazel. As described above and in #1393 it could be improved to reduce some of these inhermeticities.

[mboes]

I wholeheartedly agree with @aherrmann's plan. Are there followup issues to file? That way we can close this one.

[aherrmann]

@mboes Thanks for the reminder. I think #1320 and #1393 already capture this. I'll close this one.