No, but I do have an issue open about implementing it:
opened 07:43AM - 05 Dec 22 UTC
enhancement
help wanted
high-priority
Currently, stacklock2nix exposes Nixpkgs-compatible Haskell package set overlays… , created from the contents of the `stack.yaml` and `stack.yaml.lock` files. Here's an example of explicitly taking these overlays and applying them to an existing package set:
https://github.com/cdepillabout/stacklock2nix/blob/ac3578398a67d74382488974b385981123dd7a87/my-example-haskell-lib-advanced/nix/overlay.nix#L15-L30
If you take these overlays and apply them to an existing Nixpkgs Haskell package set (as done in the above code), the resulting Haskell package set will obviously contain packages that _aren't_ in your `stack.yaml` or `stack.yaml.lock` files.
For example, the [`cachix`](https://hackage.haskell.org/package/cachix) package is in the Nixpkgs Haskell package sets, but it is not in Stackage. So if you use `stacklock2nix` to create overlays from a local `stack.yaml` and `stack.yaml.lock` file, and apply those overlays to a normal Nixpkgs Haskell package set, the resulting package set will contain a `cachix` derivation.
Instead of just exposing overlays, it would be nice if `stacklock2nix` also made it easy to create a completely new package sets. That way, you can be sure you are only using/building packages defined in your `stack.yaml.lock` file, and not additional Haskell packages from Nixpkgs.
I'm not sure what sort of API this would look like for `stacklock2nix`, or what additional attributes it should expose for this functionality.
However,
In practice this isn’t a problem.
stacklock2nix generates a set of overrides for the packages in stack.yaml.lock. These overrides are all calls to callHackage (or callCabal2nix), so a “new” package is generated for each attribute. stacklock2nix never “reuses” packages from the Haskell package set in Nixpkgs.
So the versions of the Haskell packages you get from stacklock2nix will be the exact versions specified in your stack.yaml.lock file.
(The downside of this is that Nixpkgs may contain a helpful override that is necessary to get some arbitrary Haskell package building with Nix. I’ve moved quite a few of these overrides to stacklock2nix in stacklock2nix/suggestedOverlay.nix at ebe40119dea257906044ecb1543c44ca57748764 · cdepillabout/stacklock2nix · GitHub , which is exposed here , but I haven’t moved over everything.)
I added a FAQ entry for this:
committed 09:14AM - 29 Dec 22 UTC
This is from domenkozar in https://discourse.nixos.org/t/announcing-stacklock2ni… x-easily-build-a-haskell-project-that-contains-a-stack-yaml-lock-file/23563/20?u=cdepillabout.
