search

Gabriella439 / haskell-nix

Nix and Haskell in production
1.14k stars 116 forks source link

dealing with Cabal "data-files" when minimizing closures #12

Open shajra opened 7 years ago

shajra commented 7 years ago

When minimizing closures, dependencies on projects like ekg that use Cabal "data-files" will have resultant binaries with baked-in references to the shared library of ekg in /nix/store. This makes the transitive closure bloat out again -- even when following the practice of statically linking and copying the final executable into a standalone derivation.

So I ended up doing the hack in this gist: https://gist.github.com/shajra/afed560778a556e487b201b5b4c2ad52

It's definitely a hack, but it works. I tried to figure out a less hacky way to do this with Cabal, but made no real progress.

This is one of those things that's half Haskell, half Nix, so it's not always clear which community to go to first for help. This project seems like a way to get some intersectional conversation.

I'll leave it to @Gabriel439's discretion of how/whether to adjust this project. I don't know if there's a point where advanced topics are more of a distraction than help. Mostly, I wanted feedback. And if we reach a consensus, we can see how it affects the guide or not.

Gabriella439 commented 7 years ago

This sort of thing is definitely welcome in this project! Give me some time to review this more closely but I would like to include a solution for this if possible

Gabriella439 commented 7 years ago

@shajra: Have you considered contributing this strings-replace utility upstream to nixpkgs? It seems like something generally useful to add to the standard environment

shajra commented 7 years ago

@Gabriel439 I just wrote it recently, so I just started vetting it here, but a next step might well be to vet it in nixpkgs. It sounds like the approach makes sense to you, even given what you know about Cabal (which I'm guessing is more than me). Nixpkgs already has enough hair-brained hacks, so I'd hate to push through one more -- only to find out it wasn't really needed.

Someone pointed out a nukeReferences in nixpkgs, which is in a similar vein. strings-replace would probably end up a sibling to it. I'll point this issue to that PR when I make it, and we can both continue the conversation there.

Gabriella439 commented 7 years ago

So really the right solution is https://github.com/NixOS/nixpkgs/issues/4504. I recommend reading that thread which also discusses this same issue

shajra commented 7 years ago

Thanks for finding that issue and linking to it. My current thinking is that strings-replace might help us with a stop gap, while they sort out NixOS/nixpkgs#4504. But I'd understand if someone said, "no, let's do this right." In which case, nothing stops me from having an external copy of strings-replace to help me in a pinch. Thanks again, and I'll keep you in the loop.

shajra commented 7 years ago

@Gabriel439 you may have seen this, but Eelco showed me a nifty replace-literal tool that does something very similar to what I'm doing with strings-replace -- similar enough that I really don't need strings-replace at all.

My example-nix project has this change integrated -- in case you want to see it in play.

I'll leave it to you to leave this issue open or closed as you see fit. Thanks for helping me work this out.

Gabriella439 commented 7 years ago

I believe this is actually fixed in nixpkgs 17.09. They now support separate data outputs (and newer versions of cabal2nix enable that by default) so that should produce smaller closures