No, but I do have an issue open about implementing it:
https://github.com/cdepillabout/stacklock2nix/issues/3
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:
https://github.com/cdepillabout/stacklock2nix/commit/ebe40119dea257906044ecb1543c44ca57748764