使用nix时不使用stack --nix的原因是什么？

Question

我在，NixOS但我认为这个问题应该适用于任何使用的平台nix。

我通过试用发现stack可以与几个选项一起使用来构建项目，但我不完全了解它们之间的区别，

1. stack
2. stack --system-ghc
3. stack --nix

问题：

1. 如果我使用的是nix（在我的情况下为NixOS），我有什么理由不想使用--nix参数吗？
2. nix处理haskell项目的方式是什么，应该使用cabal（cabal2nix）代替stack？
3. 我发现堆栈正在重建许多已经由安装的库nix，这是什么原因？

Answer 1

1. 据我了解，--nix堆栈选项使用 anix-shell来管理非 Haskell依赖项（而不是要求它们位于运行堆栈的“全局”环境中）。如果您想stack在 nix 上使用该工具，这可能是个好主意。Stack 通常还安装自己的 GHC：该--system-ghc选项可以防止这种情况，并要求它在运行它的“全局”环境中使用 GHC。我相信使用--nix,stack也会要求 Nix 处理 GHC 版本控制，因此在 Nix 系统上，我建议使用--nix和不使用--system-ghc

2. 至少在我看来，在使用 Nix 时最好避免使用堆栈工具。这是因为 stack，即使使用 运行--nix，也不会通知 Nix 它想要构建的 Haskell 包：它在 内部构建它们~/.stack，并且不与 Nix 存储共享它们。如果您的项目使用最新nixpkgs版本的 Haskell 软件包构建，或者对这些软件包进行相对较少的简单覆盖，那么cabal2nix这是一个很好的解决方案，它将确保 Haskell 库仅构建一次（由 Nix 构建）。如果您想确保使用相同的软件包版本构建项目stack，我会推荐stackage2nix或stack2nix。我个人一直在使用nixpkgs-stackage覆盖层，它与以下内容相关stackage2nix：这为您提供了 nixpkgs 中的 LTS 软件包集，并且nixpkgs.haskell.packages.stackage.lib.callStackage2nix您可以在default.nix/中使用它们shell.nix，如下所示：callStackage2nix (baseNameOf ./.) (cleanSource ./.).${(baseNameOf ./.)}，无论什么定义cleanSource适合您的项目（这可以使用filterSource删除一些实际上不应该被视为项目一部分的文件，例如自动保存、构建目录等）。

   通过此设置，stack您应该使用此设置nix-shell来设置一个环境，在该环境中 Nix 构建了项目的所有依赖项并“安装”了它们，而不是使用工具来进行项目的交互式工作。然后，您可以仅使用它cabal-install来构建您的项目，而无需任何依赖项问题或（重新）构建依赖项。

3. 如上所述，stack不与 Nix 协调，并尝试在~/.stack. 如果您想将所有 Haskell 包保留在 Nix 商店中（我推荐），同时遵循与 Stack 相同的构建计划，您将需要使用链接工具之一或类似的工具。