Filter package sources

[nmattia]

When stackage2nix is used alongside stack, it is likely that the local packages contain a .stack-work/ folder. Those can quickly grow in size, and when putting the src of the derivation in the store Nix will first try to load up the whole directory in memory. With 6GB+ stack-work/ dirs this quickly becomes a problem.

One solution would be to use cleanSources or builtins.filterSource directly when generating the nix code, assuming that users will never want to have the stack-work/ directories in their nix store. Another solution would be to allow passing a custom filter, potentially operating on the package name for greater flexibility.

[4e6]

Yes, I can imagine there might be a problem with .stack-work on a large project.

But I prefer when stackage2nix generate minimal configuration required to build the project. My concern is that every configuration option that we add will require support in the future. And I would like to keep things as simple as possible.

Alternatively, you can do customizations Nix way, by overriding the resulting Haskell packages:

$ cat override.nix
with import <nixpkgs> {};
let
  haskellPackages = import ./. {};
  stackWorkFilter = name: type: let baseName = baseNameOf (toString name); in ! (
    (type == "directory" && baseName == ".stack-work")
  );
in haskellPackages.override {
  overrides = self: super: {
    stackage2nix = super.stackage2nix.overrideAttrs (attrs: {
      src = builtins.filterSource stackWorkFilter attrs.src;
    });
  };
}

Will this approach work for you?

[dhess]

I have a library of useful Nix functions which includes, among other things, source filters that are useful for Haskell projects:

https://github.com/quixoftic/nixpkgs-lib-quixoftic/blob/e79c73c3bf5673ce230d6ea253ad95249943909a/overlays/lib.nix#L69

Feel free to use the library — you can load it as an overlay that will extend lib in nixpkgs — or you can just copy the code and use it directly.