Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

callPackage wrapper #46

Open
lf- opened this issue Jul 17, 2020 · 2 comments
Open

callPackage wrapper #46

lf- opened this issue Jul 17, 2020 · 2 comments

Comments

@lf-
Copy link

lf- commented Jul 17, 2020

I have a bunch of cabal2nix output files that use src = ./. which I would like to consider gitignore for. It would be really useful if there was a wrapper that took the output from callPackage on these and replaced the source field with a gitignored one so I can just directly cabal2nix these without having to put any modifications in these autogenerated files.

@roberth
Copy link
Member

roberth commented Jul 17, 2020

That's something that should be solved in Nixpkgs Haskell. Coupling with arbitrary users of the gitignore functions invites a lot of churn and temptation to create all sorts of backwards compatibility contraptions.
I'll have a look if Nixpkgs Haskell can be improved soon, but for now I recommend wiring it up yourself. Something like this might work, although I haven't tested it. Experimenting in nix-repl does indicate that it's not strict in src so it should be possible.

  self: super:
    let
      callPkg = cabal2nixFile: args: 
        let drv = super.callPackage cabal2nixFile args;
        in haskell.lib.overrideSrc { src = gitignoreSource drv.src; };
    in {
      # your overlay stuff
      # my-package.nix is a placeholder cabal2nix generated nix file
      my-package = callPkg ./my-package.nix {};
    }

That's assuming you use an overlay (probably should if you have multiple packages). If not you could pull out callPkg.

I wonder why you're using committed cabal2nix files. Have you tried other options like callCabal2nix or haskell.nix?

@lf-
Copy link
Author

lf- commented Jul 17, 2020

I have considered those and chose not to use them. The primary reason for such is build performance, specifically, callCabal2Nix would make it take about 15 seconds longer (and I've not tested yet whether it needs regeneration if just source files are modified rather than the cabal file).

Thank you for writing that code snippet. That definitely looks like the best approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants