使用nix时不使用stack --nix的原因是什么? [英] What is reason not to use stack --nix when I using nix?

查看:97
本文介绍了使用nix时不使用stack --nix的原因是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在NixOS上,但我认为此问题应适用于使用nix的任何平台.

I am on NixOS but I think this question should apply to any platform that use nix.

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

I found by trial that stack can be used with couple options to build a project but I don't fully understand difference among them,

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

问题:

  1. 如果我使用的是nix(在我的情况下为NixOS),有什么理由我不想使用--nix参数吗?
  2. 处理haskell项目的nix方法是什么,应该使用cabal(cabal2nix)代替stack吗?
  3. 我发现堆栈正在重建nix已经安装的许多库,这是什么原因?
  1. If I am using nix (NixOS in my case), is there any reason I will want to not use --nix argument?
  2. What is the nix way to deal with haskell project, should cabal (cabal2nix) be used in stead of stack?
  3. I found that stack is rebuilding lots of libraries that already installed by nix, what is the reason of that?

推荐答案

  1. 据我了解,用于堆叠的--nix选项使用nix-shell来管理 non-Haskell 依赖项(而不是要求它们处于全局"环境中)该堆栈是从中运行的).如果要在nix上使用stack工具,这可能是一个好主意.堆栈通常还安装自己的GHC:--system-ghc选项可防止这种情况,并要求其在全局"目录中使用GHC.运行环境.我相信使用--nix时,stack也会要求Nix处理GHC版本控制,因此在Nix系统上,我建议使用--nix而不使用--system-ghc

  1. As I understand it, the --nix option to stack uses a nix-shell to manage non-Haskell dependencies (instead of requiring them to be in the "global" environment that stack is run from). This is probably a good idea if you want to use the stack tool on nix. Stack also usually installs its own GHC: the --system-ghc option prevents this, and asks it to use the GHC in the "global" environment from which it is run. I believe that with --nix, stack will ask Nix to handle GHC versioning as well, so on a Nix system, I would recommend building with --nix and without --system-ghc

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

At least in my opinion, it is better to avoid the stack tooling when working with Nix. This is because stack, even when run with --nix, does not inform Nix about the Haskell packages that it wants to build: it builds them all itself inside ~/.stack, and doesn't share them with the Nix store. If your project builds with the latest nixpkgs versions of Haskell packages, or with relatively few simple overrides on those, cabal2nix is a great solution that will make sure that Haskell libraries only get built once (by Nix). If you want to make sure that you are building your project with the same package versions as stack would, I would recommend stackage2nix or stack2nix. I personally have been using the nixpkgs-stackage overlay, which is related to stackage2nix: this gives you both LTS package sets in nixpkgs, and nixpkgs.haskell.packages.stackage.lib.callStackage2nix, which you can use in your default.nix/shell.nix like so: callStackage2nix (baseNameOf ./.) (cleanSource ./.).${(baseNameOf ./.)}, with whatever definition of cleanSource fits your project (this can use filterSource to remove some files which shouldn't really be considered part of the project, like autosaves, build directories, etc.).

使用此设置,而不是使用stack工具,对于项目上的交互工作,您应该使用nix-shell来设置Nix构建了项目的所有依赖项并安装"环境的环境.他们.然后,您可以使用cabal-install仅构建您的项目,而不会出现任何依赖关系问题或(重新)构建依赖关系.

With this setup, instead of using the stack tooling, for interactive work on the project you should use nix-shell to set up an environment where Nix has built all of the dependencies of your project and "installed" them. Then you can just use cabal-install to build just your project, without any dependency issues or (re)building dependencies.

如上所述,stack不与Nix协调,而是尝试在~/.stack中自身构建每个Haskell依赖项.如果要在遵循与Stack相同的构建计划的同时将所有Haskell软件包保留在Nix商店中(我建议这样做),则需要使用一种链接工具或类似的工具.

As mentioned above, stack does not coordinate with Nix, and tries to build every Haskell dependency itself in ~/.stack. If you want to keep all of your Haskell packages in the Nix store (which I would recommend) while following the same build plans as Stack, you will need to use one of the linked tools, or something similar.

这篇关于使用nix时不使用stack --nix的原因是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆