Nixify Stack project - Nix

So I moved to a NixOS machine a while back and I haven't done any Haskell development in it really. But I'm looking to build a Stack project and not sure how to go about things like getting the right GHC version.

Can people point me to some resources for getting up to speed with taking an existing Stack based project and building it using Nix? I'm also just cargo culting Nix still so I really need to get a grip on how to write derivations and all that jazz. I have a shallow understanding of how it all works :)

first of all, there's stack2nix

Ya I tried that and it failed to do anything which wasn't inspiring. And then I got the sense it was abandoned for their haskell.nix project

right hm

so how customized is your stack config?

and what's your development workflow? ghcid?

or stack build

It's the unison project

So I just wanna stack build to get the executable

If I learn other stuff along the way then that's a bonus :grinning_face_with_smiling_eyes:

then you basically want to get to the point where you run nix-build -A ghc.unison

so your nix expression needs to choose a ghc from nixpkgs and stuff it with package overrides

you choose a ghc by saying pkgs.haskell.packages.ghc884, choosing the version you want

Makes sense :ok:

then you call ghc.override { overrides = myOverrides; }

where myOverrides has the shape finalGhc: previousGhc: { conduit = finalGhc.callCabal2nix "conduit" /home/fintan/conduit; ... }

where finalGhc and previousGhc are ways to say "I want to use whatever is gonna be the override at the end" and "I want to override this"

Annnd I'm lost a bit :sweat_smile: at a high level I think this makes sense but writing the derivation is still a bit beyond me

and whatever is in that set is used as a package db

:smile:

so, example

use that as default.nix and run nix-build -A ghc.unison-core

(updated with the correct names)

Ya was realising it was under unsion-core :smile:

I'm getting a syntax error on in :thinking:

Ah, missed a curly

updated it so that ghc is actually an attribute

So, now I'm getting error: attribute 'ghc884' missing, at /home/haptop/Developer/unison/default.nix:4:9

What does your brain say when you see this error? Like I wanna know what steps I should think about when I come across something like this

well, first thought is that I either used the wrong attribute path or that your nixpkgs doesn't have ghc 8.8.4

Also it seems like the resolver unison uses points to 8.8.3

Hmmm, but I'm _pretty_ sure I'm using 20.03

well, those are details that aren't necessary to get the derivation working but you can just use 883

so change it to 883 and then try, for example, nix-build -A ghc.aeson

Which details aren't necessary?

then if it works, just ctrl-c

It does not :grimacing:

Still missing the attribute

which compiler version to use. we just want to get the nix expression right, not build successfully :smile:

ok just a sec

Appreciate the help :bow:

try import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/773ef5ae78339db744b917c2b35d28812028bd8c.tar.gz") {}

my pleasure :smile:

Would that go before the let?

(instead of import <nixpkgs>)

I see

So we're just pinning the packages to that archive entry?

yeah just to be sure nothing in your env is overriding

Seems to be working

awesome!

There's compiling Haskell at least :sweat_smile:

then you can start trying nix-build -A ghc.unison-core

That's what I've ran :)

now the stack dep overrides. you'll want to add an attribute for each to your ghc, just like unison-core. then there's multiple variants for adding packages:

strings = finalGhc.callHackage "strings" "1.1" {};

this is the simplest, and requires that this version is in the curated set in nixpkgs

So I should stop the build?

if not, you'll need callHackageDirect { pkg = "strings"; ver = "1.1"; sha256 = "asdkfjasdkfj"; } where you'll have to either put a wrong sha in there and wait for nix to tell you the right one (do not use the sha of another package, it will use that then) or use nix-prefetch-url with the hackage url

well you can run it till you get an error if you like and hack on the file in the meantime :smile:

but if there's a late version conflict of a very general package, all of its deps will be rebuilt

and the last one would be github deps

Ahhh fair enough

So, these entries go into the override set?

Where did you find strings from? :thinking:

exactly, as attributes just like unison-core

from stack.yaml

Oh in the extra deps

Ok, I'll have to come back to this later. I should do some work-work :joy: Thanks for getting me going on this @Torsten Schmits :heart:

happy to help :upside_down:

I use haskell.nix for this, but it has some annoyances

codygman said:

I use haskell.nix for this, but it has some annoyances

what are those?

If you want to use stack inside of a nix shell that uses Nix installed packages you have to do this and it's brittle when packages changed because stack will try to install them:

https://github.com/codygman/haskell-nix-stack-workflow/tree/e66a50e2be2706724174b2e7d3c5e4a884f42179

Err you probably want master instead of that tree if you try it. Related discussion: https://github.com/input-output-hk/haskell.nix/issues/689#issuecomment-683658719

why stack inside of nix-shell? we were replacing stack here

Oh, my mistake. Here I wanted to use stack as a dumb frontend but have nix do the real work. If you think stacks UX is nicer to use or your team does, this is nice.

Why not use stack --nix? To avoid specifying dependencies anywhere but default.nix and package.yaml, work with direnv, and probably other things I forgot.

interesting proposition!

I've been challenging that proposition by using stack --nix more as of late though. I'm undecided which approach I think is better.

do you have a list of features that have significantly better UX in stack?

I moved over to cabal by default recently to rediscover those and challenge that view, so not yet.

However these come to mind:

• stack build --profile
• stack build --fast
• hpack maybe but yaml dangerous
• stack new (I think this might not be true anymore?)
• stack ghci loading everything by default.. or for some reason cabal doesn't have everything I expect

and haskell.nix doesn't offer adequate replacements?