Make a package in nixpkgs without GHC in closure

[SenchoPens]

Hi, currently installing haskellPackages.steeloverseer adds up to 2,5Gb of disk storage because it has GHC in closure. The size makes this package hard to add to a development environment, because sharing it with people will imply them downloading 2,5Gb of data. Maybe there is a way to package this wonderful app as they packaged pandoc (it weighs around 200Mb)?
See NixOS/nixpkgs#34376

[schell]

That would be great! Unfortunately I am currently traveling. Nix is also not in my skill set. I think @mitchellwrosen or @imalsogreg did the original Nix integration. I would also welcome a pull request!

[schell]

Oh, huh - looks like there's no nix files in this repo. How is it that steeloverseer is in nixpackages to begin with?

[imalsogreg]

It's on hackage, so the hackage-to-nix infrastructure is pulling it into haskellPackages from there.

I don't see which steeloverseer dependency could be blowing up the closure size - just a guess, maybe every non-statically-linked Haskell project would pull GHC in as a dependency?

Probably the best solution here is a PR against nixpkgs with a recipe for building a statically linked steeloverseer binary - the attribute would then live under pkgs rather than pkgs.haskellPackages (since the Haskellness is just an implementation detail).

[schell]

I see now. Thanks for the explanation @imalsogreg ! I think this would be a considerable amount of work. The last time I tried full static linking in Haskell it was tricky.

[imalsogreg]

You're welcome :) I know of a couple tools that have done it - dhall and pandoc. In each case yeah I think there was some work involved. @SenchoPens if you'd like to give it a try, looking at how dhall (the cli tool, not the haskell package) is defined in nixpkgs as an example, I'm happy to advise!

[SenchoPens]

Thanks! I'll definitely look into it once I have some spare time. Thanks for offering help!