Custom packaging requirements: will we end up recreating nixpkgs?

[lunaris]

Some packages (I think) require custom build instructions to compile properly in the environment that Hazel, rules_haskell and (assuming this is the default mode of usage for rules_haskell) Nix/nixpkgs. As an example, cryptonite-0.25 contains an extra-lib: pthread declaration that states it must be linked with the pthread library on POSIX. To get this to work, the rough steps are something like:

• Pull in glibc from nixpkgs using nixpkgs_package with a custom BUILD that uses patchelf (also pulled in from nixpkgs) to patch libpthread and expose it.
• Pass libpthread to extra_libs when configuring Hazel.
• Build @haskell_cryptonite
• Get an error because libpthread.so is in fact an ld script that combines the dynamic and static portions of the library.
• ... etc. ...

In short a custom build process for a working copy of libpthread needs to be devised in Bazel and then supplied using extra_libs to Hazel. Having already encountered this issue for libstdc++ (and not really considering that it might bite in other forms), https://github.com/tweag/rules_haskell/pull/387 lays out what I thought a better interface to rules_haskell might be to enable users of rules_haskell and Hazel to navigate this situation a bit better. However, on encountering this and also examining bits of Hazel such as the custom BUILD.*s for wai, conduit, etc., I'm wondering -- are we destined to implement a similar effort to the one already being undertaken by nixpkgs, whereby there is a large amount of custom packaging for finicky cases like this? If so, do we want to undertake this work? If not, what is the alternative (e.g. should we just use Haskell packages from nixpkgs and only offer things like *_custom_package_github for non-Hackage-package cases)?

CC @mboes since perhaps this affects rules_haskell/there has been discussion around this already.

[mboes]

If so, do we want to undertake this work? If not, what is the alternative (e.g. should we just use Haskell packages from nixpkgs and only offer things like *_custom_package_github for non-Hackage-package cases)?

Fair question! I think there's no clear answer. There are two broad strategies available currently:

Outsource handling all of Hackage/Stackage code to Nixpkgs

Pros:

• we don't have to fiddle with the intricacies of system dependencies for each package ourselves,
• we get to use the official Nixpkgs binaries caches without any extra setup,
• and it's dog simple.

Cons:

• imposes the use of Nix, which is a large dependency if it isn't otherwise required/desirable,
• Nix brings along its own fairly substantial "cognitive overhead" (@judah's words) that some would prefer to avoid,
• relying on Nixpkgs works great when the package versions upstream match what you want, but it's a lot more hassle if you have to customize these versions,
• our current implementation causes more rebuilds than necessary when the set of Hackage dependencies change (see https://github.com/tweag/rules_haskell/issues/75), because Bazel thinks we effectively have a whole new toolchain every time we add a new dependency.

Be Bazel native (i.e. use Hazel)

Pros:

• Bazel handles (and builds itself) all dependencies uniformly, meaning just one build cache to manage,
• No need to write any nix code (though that's also true of the above strategy for the common cases),
• Better portability (Nixpkgs doesn't do Windows while Bazel does).

Cons:

• More work - need Hazel + rules_haskell rather than just rules_haskell.

For people with lots of system dependencies, Nixpkgs could well be the better option, because in such a use case you want to carefully manage the versions of system dependencies and Nix is a good way to do that anyways. For those who don't, having everything in Bazel and not dealing with Nix at all is quite nice. In the latter use case, it doesn't matter much that Hackage packages that depend on external libraries require more work that is already done in Nixpkgs. And if you need the portability, it's probably your only option.

[lunaris]

I've been playing with this for a week or so now and it's tricky. Some packages are fairly straightforward to sort out (postgresql-simple, libpq), others less so (libssh2 due to its use of c2hs and company). I'm going to see how I fare using Nix for a select few base packages (essentially anything that steps outside "pure Haskell" on Hackage) -- in theory these dependencies shouldn't change that often. It does seem somewhat untenable to put in the same amount of work that has already been expended in nixpkgs again in Hazel/rules_haskell.

[shmish111]

@lunaris how exactly did you solve this in the end? I'm currently trying to build a project which uses cryptonite and running into this issue

[lunaris]

In the end we moved to use the Nixpkgs support exposes by rules_haskell for Hackage packages (since that arrived at about the time I raised/potentially partly in response to this issue). Disadvantages include having to manage two caches and bits of build process, advantages are leveraging the packaging efforts of the Nixpkgs community. So far it seems to work very well.

On Wed, 13 Feb 2019, 16:00 David Smith <notifications@github.com wrote:

@lunaris https://github.com/lunaris how exactly did you solve this in the end? I'm currently trying to build a project which uses cryptonite and running into this issue

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormationAI/hazel/issues/41#issuecomment-463255584, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJ_0bo2xYLAIjGHgfsdXgsn7q-j7fp4ks5vNDa2gaJpZM4WBYQ2 .

[shmish111]

what do you mean, you import cryptonite from nixpkgs? were you able to use this with hazel?

[lunaris]

Yes, sorry. In short, we don't use Hazel -- all Hackage packages come from Nixpkgs (using rules_haskell which in turn uses rules_nixpkgs). Nix thus takes care of building those packages/special rules and foreign interface trickery etc.; we only manage Bazel rules (like haskell_library) for code we write.

On Wed, 13 Feb 2019, 16:20 David Smith <notifications@github.com wrote:

what do you mean, you import cryptonite from nixpkgs? were you able to use this with hazel?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormationAI/hazel/issues/41#issuecomment-463263737, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJ_0dzbGILgy6vVta8T5o9IyZiPBVBKks5vNDtpgaJpZM4WBYQ2 .

[shmish111]

ok thanks. I found there was way too much boiler plate using nixpkgs haskell packages, especially with a multi-module project. I had to repeat similar code in 3 or more places.

[shmish111]

I don't suppose you have some idea of how it would be possible to patch it so that hazel could use it? As of this moment I have hacked things by getting nixpkgs to manage this one package, not very nice at all.