No, but I do have an issue open about implementing it:
opened 07:43AM - 05 Dec 22 UTC
closed 11:41PM - 09 Feb 23 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 https://github.com/cdepillabout/stacklock2nix/blob/ebe40119dea257906044ecb1543c44ca57748764/nix/build-support/stacklock2nix/suggestedOverlay.nix , 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.
I posted about stacklock2nix on the Haskell Discourse as well:
A few weeks ago I put together a Nix library stacklock2nix. It enables you to easily build a Stack-based Haskell project with the Haskell infrastructure from Nixpkgs: stacklock2nix is an alternative to haskell.nix for projects that: you want...
Reading time: 1 mins 🕑
Likes: 5 ❤
It is possible there may be interesting/relevant comments there.
I implemented this feature in the latest release:
1 Like