如何让阴谋集团和尼克斯一起工作

Question

据我所知，Nix是阴谋沙箱的替代品。我终于成功地安装了Nix，但我仍然不明白它如何能够取代沙箱。

我知道您不需要使用Nix和包装的GHC版本的阴谋；但是，如果您想发布一个包，您需要在某个时候使用阴谋来打包它。因此，您需要能够在NIX中编写和测试您的阴谋配置。你怎么做到的？

理想情况下，我想要一个类似于阴谋沙箱但在NIX中“包含”的环境，这可能吗？事实上，我真正想要的是嵌套沙箱--因为我通常处理由多个包组成的项目。

更新我当前的工作流程

目前，我从事2或3个独立项目(P1、P2、P3)，每个项目由2或3个阴谋模块/包组成，比如P1: L11、L12 (库)和E11 (可执行文件)。E11依赖于L12，而依赖于L11。我主要将可执行文件从图书馆中分离出来，因为它们是私有的，并且保存在私有的git上。

理论上，每个项目都可以有自己的沙箱(在子模块之间共享)。我尝试过这样做(为L11 L12和E11提供了一个通用的沙箱)，但它很快就很烦人，因为如果您修改了L11，您就无法重新构建它，因为E11依赖于它，所以我必须先卸载E11才能重新编译L11。情况可能不是这样，但我遇到了类似的问题。如果我偶尔修改L11，这会很好，但是在实践中，我对它做了更多的修改，而不是E11。

由于共享沙箱不起作用，所以我回到了每个包解决方案的一个沙箱中。它正在工作，但不太理想。主要问题是，如果修改L11，需要编译两次(一次在L11中，然后在E11中)。而且，我每次启动一个新的沙箱，大家都知道，我需要等待一段时间才能下载和重新编译所有的包。

因此，通过使用Nix，我可以为每个项目设置单独的阴谋“环境”，这解决了上面所有的问题。

希望这更清楚。

Answer 1

这些天，我使用Nix和阴谋来做我所有的开发工作，我可以很高兴地说，它们非常和谐地工作。我当前的工作流程是非常新的，因为它依赖于nixpkgs中刚刚到达主分支的特性。因此，您需要做的第一件事是从Github克隆nixpkgs：

cd ~
git clone git://github.com/nixos/nixpkgs

(在未来，这是不必要的，但现在是必要的)。

单项目使用

既然我们有了一个nixpkgs克隆，就可以开始使用haskellng包集了。haskellng是对我们如何在Nix中打包东西的重写，我们感兴趣的是更可预测(包名与黑客包名称匹配)和更可配置。首先，我们将安装cabal2nix工具，它可以为我们自动化一些事情，我们还将安装cabal-install来提供cabal可执行文件：

nix-env -f ~/nixpkgs -i -A haskellngPackages.cabal2nix -A haskellngPackages.cabal-install

从现在起，一切都很清楚。

如果您正在启动一个新项目，您可以像通常那样在一个新目录中调用cabal init。准备构建时，可以将此.cabal文件转换为开发环境：

cabal init
# answer the questions
cabal2nix --shell my-project.cabal > shell.nix

这为您提供了一个shell.nix文件，可以与nix-shell一起使用。不过，您不需要经常使用它--通常使用它的唯一时间是与cabal configure一起使用

nix-shell -I ~ --command 'cabal configure'

cabal configure缓存到所有东西的绝对路径，所以现在当您想要构建时，只需正常地使用cabal build：

cabal build

每当您的.cabal文件更改时，您都需要重新生成shell.nix --只需运行上面的命令，然后再运行cabal configure。

多项目使用

这种方法可以很好地扩展到多个项目，但它需要更多的手工工作才能将所有东西“粘合在一起”。为了演示这是如何工作的，让我们考虑一下我的socket-io库。这个库依赖于engine-io，我通常同时开发这两个库。

Nix化该项目的第一步是沿每个单独的default.nix文件生成.cabal表达式：

cabal2nix engine-io/engine-io.cabal > engine-io/default.nix
cabal2nix socket-io/socket-io.cabal > socket-io/default.nix

这些default.nix表达式是函数，所以我们现在不能做很多事情。为了调用这些函数，我们编写了自己的shell.nix文件，说明如何将所有内容组合在一起。对于engine-io/shell.nix，我们不需要做任何特别聪明的事情：

with (import <nixpkgs> {}).pkgs;
(haskellngPackages.callPackage ./. {}).env

对于socket-io，我们需要依赖于engine-io

with (import <nixpkgs> {}).pkgs;
let modifiedHaskellPackages = haskellngPackages.override {
      overrides = self: super: {
        engine-io = self.callPackage ../engine-io {};
        socket-io = self.callPackage ./. {};
      };
    };
in modifiedHaskellPackages.socket-io.env

现在我们在每个环境中都有shell.nix，所以我们可以像以前一样使用cabal configure。

这里的关键观察是，每当engine-io更改时，我们都需要重新配置socket-io以检测这些更改。这就像运行一样简单

cd socket-io; nix-shell -I ~ --command 'cabal configure'

Nix会注意到../engine-io已经更改，并在运行cabal configure之前重新构建它。