You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stack2nix is cool if you have to maintain a stack.yaml and want a reliable way to turn it into a nix file. However it does not work well as a migration tool yet.
For instance here is the haskell-ide-engine stack.yaml. Stack2nix outputs a 1.59MB nix file that pins all the haskell packages. This means you can't change nixpkgs to get different haskell packages versions (you will always get the ones stack would have chosen). This locks you into maintaining a stack.yaml file and running stack2nix (instead of bumping nixpkgs to a newer commit).
I think if stack2nix took a nixpkgs ref as an input it could get much closer to the hand crafted translation. It could compare the nixpkgs derivations to the ones it would have output and only output the differences.
Here is an example of a by hand translation and I think something like stack2nix --migrate --nixpkgs '<nixpkgs>' should be able to get pretty close to this:
If ./ is included as package, the list of files passed to onlyFiles should be added to prevent non package files from triggering builds (I made that list by running cabal sdist and looking at the top level items in the .tar.gz file it produced).
The text was updated successfully, but these errors were encountered:
The main issue with mixing cabal2nix and stack is that they have different build plans. For example, cabal2nix always includes tests and benchmarks dependencies, while stack does only for packages in locations section. There are many subtle differences how they use hackage as an api and findings show mixing the two is painful to get right. I'd actually like to use cabal2nix just as low-level library in #111 and stack do the whole build plan as it sees it. This would get rid of many issues that people face with stack2nix these days.
Of course, the above is doable if one wants to live with addressing those issues manually.
For example, cabal2nix always includes tests and benchmarks dependencies, while stack does only for packages in locations section.
Could a custom version of pkgs.haskell.lib.packageSourceOverrides disable tests and benchmarks for everything except the except the packages it is overriding with callCabal2nix?
Stack2nix is cool if you have to maintain a
stack.yaml
and want a reliable way to turn it into a nix file. However it does not work well as a migration tool yet.For instance here is the haskell-ide-engine stack.yaml. Stack2nix outputs a 1.59MB nix file that pins all the haskell packages. This means you can't change nixpkgs to get different haskell packages versions (you will always get the ones stack would have chosen). This locks you into maintaining a stack.yaml file and running
stack2nix
(instead of bumpingnixpkgs
to a newer commit).I think if
stack2nix
took a nixpkgs ref as an input it could get much closer to the hand crafted translation. It could compare the nixpkgs derivations to the ones it would have output and only output the differences.Here is an example of a by hand translation and I think something like
stack2nix --migrate --nixpkgs '<nixpkgs>'
should be able to get pretty close to this:If
./
is included as package, the list of files passed toonlyFiles
should be added to prevent non package files from triggering builds (I made that list by runningcabal sdist
and looking at the top level items in the.tar.gz
file it produced).The text was updated successfully, but these errors were encountered: