Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
cabal2nix: split into a lightweight version and a wrapper #81125
However, when calling
This commit splits cabal2nix into a lightweight version that is a standalone
This commit also switches to the default ghc, to reduce the likelyhood of
Motivation for this change
cdepillabout left a comment •
Can you make this target the
This seems reasonable to me except for the following three things:
@cdepillabout Thanks for the review! Regarding your points:
edit: Ah, I see that would end up pulling a cabal2nix built with a version of ghc depending on the haskell package set.
Yeah, I agree that we don't have many good solutions here.
I think I am okay with having
I need to try running this once or twice, but I think it should be pretty good as-is.
Not really: we want
On the other hand, we can decide we don't care about the (binary) duplication, and just use
In the end, if the duplication of binary is acceptable, then changing
I hope you don't mind, I just pushed a change so it doesn't need a whitelist of paths to be copied from the unwrapped derivation. Makes it a bit more succinct. The
Current, the `cabal2nix` derivation contains both the executable, and a wrapper that adds `nix` and `nix-prefetch-scripts`, which are required for some features. However, when calling `callCabal2nix` to create a derivation from a cabal file at evaluation time, these features are not actually used, but the huge closure of `nix-prefetch-scripts` (which includes multiple vcs, as well as python and perl) still needs to be fetched. This commit splits cabal2nix into a lightweight version that is a standalone static binary (`cabal2nix-unwrapped`), and a wrapper that includes the proper dependencies in the path for full usage of the command line utility (`cabal2nix`). This commit also switches to the default ghc, to reduce the likelyhood of building a different ghc when calling `callCabal2nix`.
@GrahamcOfBorg build cabal2nix
@GrahamcOfBorg build cabal2nix-unwrapped
I've also tested this with the command:
As far as I could tell, it looks like it didn't have to pull in a bunch of language runtimes, so it worked as expected.