新闻详情

新闻详情

首页 / 资讯中心 / 详情

使用 devenv 声明式配置 Haskell 开发环境:GHC、Cabal、Stack 与 HLS 全解析

发布时间:2026/9/29 5:55:09来源:尧图网络
使用 devenv 声明式配置 Haskell 开发环境:GHC、Cabal、Stack 与 HLS 全解析
开发工具CLI【免费下载链接】devenvFast, Declarative, Reproducible, and Composable Developer Environments using Nix项目地址https://gitcode.com/gh_mirrors/de/devenv点击查看免费下载本文以 devenv 项目一个基于 Nix 的快速、声明式、可复现、可组合的开发环境工具中的 Haskell 语言支持模块为核心讲解如何通过languages.haskell.*一组 Nix 选项一键搭建包含 GHC 编译器、Cabal、Stack 与 Haskell Language ServerHLS的完整 Haskell 开发环境。读完本文你将掌握全部 9 个配置选项的含义与默认值、底层模块如何组装工具链并能针对自己的项目定制编译器版本与构建工具参数。概述一个enable true带来的完整 Haskell 工具链在 devenv 中Haskell 语言支持被封装为languages.haskell模块定义于 src/modules/languages/haskell.nix。只需在devenv.nix中写入{ pkgs, ... }: { languages.haskell.enable true; }运行devenv shell或通过 direnv 自动加载后环境即包含GHC 编译器默认pkgs.ghczlib与hpack默认随编译器一起加入hpack 用于将package.yaml转换为 Cabal 文件Haskell Language ServerHLS默认启用且自动匹配当前 GHC 版本Cabal默认启用来自pkgs.cabal-installStack默认启用并自动包装为使用 devenv 提供的 GHC。文档层面该模块对应的完整选项参考由docs/src/individual-docs/languages/haskell.md模板自动生成落地为 docs/src/content/docs/languages/haskell.md下文所有选项说明均以此为准并结合源码逐项展开。核心选项详解从 enable 到各子工具languages.haskell下共有 4 个命名空间9 个可配置选项。所有布尔选项均默认开启除enable外体现出开箱即用的设计取向。languages.haskell.enable类型boolean默认值false示例true作用总开关是否启用 Haskell 开发工具。这是唯一需要手动打开的开关。源码中对应lib.mkEnableOption tools for Haskell development见 haskell.nix。其余子工具Cabal、Stack、HLS虽然在各自命名空间下也有enable但默认均为true因此只要打开总开关即可获得完整工具链。languages.haskell.package类型package默认值pkgs.ghc作用选择要使用的 Haskell 编译器。可通过覆盖 NixOS/nixpkgs 包或直接指向其他 GHC 版本{ pkgs, ... }: { languages.haskell.enable true; languages.haskell.package pkgs.ghc; # 或 pkgs.haskell.compiler.ghc982 等指定版本 }该选项是整套环境的锚点后续 HLS 的版本匹配、Stack 的 GHC 发现都围绕它展开详见下文源码分析。languages.haskell.lsp.enable与languages.haskell.lsp.package类型boolean/package默认值true/pkgs.haskell-language-server作用是否启用 Haskell Language Server以及使用哪个 HLS 包。特别注意HLS 的默认值并非原样使用pkgs.haskell-language-server而是对其进行了一次override将supportedGhcVersions固定为当前选择的 GHC 版本。这保证了语言服务器与编译器严格配套# 源码中的实际默认值构造haskell.nix L38-L46 pkgs.haskell-language-server.override { supportedGhcVersions [ ghcVersion ]; # ghcVersion 为 GHC 版本号去掉小数点如 982 }也就是说只要更换languages.haskell.packageHLS 会自动适配新编译器版本无需手动同步。languages.haskell.cabal.enable与languages.haskell.cabal.package类型boolean/package默认值true/pkgs.cabal-install作用是否启用 Cabal 构建工具以及使用的cabal-install包。Cabal 是 Haskell 生态中最常用的构建工具之一。关闭方式为languages.haskell.cabal.enable false;适用于纯 Stack 工作流。languages.haskell.stack.enable、languages.haskell.stack.package与languages.haskell.stack.args类型boolean/package/list of string默认值true/pkgs.stack/[ --no-nix --system-ghc --no-install-ghc ]作用enable是否启用 Stackpackage使用的 stack 包args传递给 stack 的额外参数。stack.args是三者中信息量最大的选项。文档说明指出默认情况下stack 被配置为使用 devenv 的 GHC 安装。默认参数的三段含义为参数含义--no-nix不使用 stack 内置的 Nix 集成避免与 devenv 的环境叠加产生冲突--system-ghc使用系统即 devenv 环境中已安装的 GHC而不是让 stack 自行下载--no-install-ghc禁止 stack 自动安装 GHC确保始终复用 devenv 提供的编译器这一组合保证了环境里有什么就用什么使构建结果可复现。需要自定义时{ pkgs, ... }: { languages.haskell.enable true; languages.haskell.stack.args [ --no-nix --system-ghc --no-install-ghc --resolver lts-22 ]; }注意stack.args的默认值是通过 makeWrapper 将参数烘焙进可执行文件的见下文因此覆盖该列表会整体替换默认参数而不是追加。源码实现剖析工具链如何组装理解 haskell.nix 的实现能让你更准确地预测配置行为。1. Stack 包装器把参数焊进可执行文件Stack 默认参数并非运行时读取的配置而是通过makeWrapper在构建期写入stack可执行文件的包装脚本stackWrapper pkgs.runCommand stack-wrapper { buildInputs [ pkgs.makeWrapper ]; } mkdir -p $out/bin makeWrapper ${cfg.stack.package}/bin/stack $out/bin/stack \ ${lib.concatMapStringsSep \\\n (arg: --add-flags \${arg}\) cfg.stack.args} ;见 haskell.nix即每个stack.args元素都会被展开成一条--add-flags arg最终得到等价于stack --no-nix --system-ghc --no-install-ghc ...的执行效果。这解释了为何覆盖stack.args会整体替换默认行为——包装器在编译环境时已经定型。2. GHC 版本号处理ghcVersion是把所选 GHC 的版本号去掉小数点后的字符串用于 HLS 的supportedGhcVersions匹配ghcVersion lib.replaceStrings [ . ] [ ] cfg.package.version;例如 GHC 9.8.2 →982。这正是 HLS 默认值与 GHC 自动配套的机制来源haskell.nix。3. 最终加入环境的包集合packages with pkgs; [ cfg.package # GHC zlib # 常见 Haskell 项目的链接依赖 hpack # package.yaml - .cabal 转换工具 ] (lib.optional cfg.lsp.enable cfg.lsp.package) (lib.optional cfg.cabal.enable cfg.cabal.package) (lib.optional cfg.stack.enable stackWrapper);见 haskell.nix可以清晰看到GHC、zlib、hpack 是无条件加入的HLS、Cabal、Stack 则各自受enable开关控制其中 Stack 加入的是经过包装的stackWrapper而非裸包。lib.optional的语义是条件为真时放入单个元素因此三个开关的关闭都能精确地从环境里移除对应工具。4. 历史选项兼容languageServer→lsp.package模块还通过mkRenamedOptionModule提供了旧配置的平滑迁移imports [ (lib.mkRenamedOptionModule [ languages haskell languageServer ] [ languages haskell lsp package ]) ];见 haskell.nix如果你曾经写过languages.haskell.languageServer ...在新版 devenv 中会被自动重定向到languages.haskell.lsp.package既不会报错也不影响行为只是推荐按新路径书写。实战三个常见配置场景场景一最小可用环境{ pkgs, ... }: { languages.haskell.enable true; }等价于显式写出全部默认值适合跟随教程快速起步。场景二指定 GHC 版本并让 HLS 自动跟随{ pkgs, ... }: { languages.haskell.enable true; languages.haskell.package pkgs.haskell.compiler.ghc982; # 示例9.8.2 # HLS 会自动 override supportedGhcVersions [ 982 ] }场景三纯 Cabal 工作流关闭 Stack或纯 Stack 工作流关闭 Cabal{ pkgs, ... }: { languages.haskell.enable true; languages.haskell.stack.enable false; # 只用 Cabal # 或反过来 # languages.haskell.cabal.enable false; # 只用 Stack }进入环境后即可直接使用ghc、cabal build、stack build、hpack、haskell-language-server等命令配合 devenv 的processes与tasks模块还可以进一步把 GHCi、测试命令声明为可复现的自动化流程。相关资源选项完整参考自动生成docs/src/content/docs/languages/haskell.md模块源码src/modules/languages/haskell.nix语言支持总览示例其中languages.haskell.enable trueexamples/supported-languages/devenv.nix小结languages.haskell模块以一个总开关 三个默认开启的子工具的形式把 GHC、Cabal、Stack、HLS 及配套的 zlib/hpack 组装成一致的开发环境。其实现要点在于HLS 通过版本号去点匹配 GHC、Stack 通过 makeWrapper 固化参数以复用 devenv 的编译器、旧选项通过mkRenamedOptionModule自动迁移。掌握这组选项后你就可以像管理其他语言一样用声明式 Nix 配置获得可复现的 Haskell 开发体验。赞分享开发工具CLI【免费下载链接】devenvFast, Declarative, Reproducible, and Composable Developer Environments using Nix项目地址https://gitcode.com/gh_mirrors/de/devenv点击查看免费下载相关推荐GitHub_Trending/ki/kickstart.nvim与Haskell开发Stack与Cabal配置GitHub_Trending/ki/kickstart.nvim与Haskell开发Stack与Cabal配置 引言Haskell开发环境的痛点与解决方案开发工具代码编辑器devenv 中 Dart 开发环境的声明式配置languages.dart 模块详解devenv 中 Dart 开发环境的声明式配置languages.dart 模块详解 导读 本文讲解如何在 devenv https://link.gitc开发工具CLIdevenv 中 Haskell 开发环境配置指南languages.haskell 选项全解析devenv 中 Haskell 开发环境配置指南 languages.haskell 选项全解析 本文以 devenv 项目中的语言模块文档 docs/sr开发工具CLI上一篇Mermaid Live Editor实战指南打造实时图表编辑的终极工作流下一篇如何自托管部署OpenReplayDocker Compose与Kubernetes等5种方式完整指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

个人开发者LLM全流程实战:从预训练到RAG的完整指南 2026/9/29 6:57:07

个人开发者LLM全流程实战:从预训练到RAG的完整指南

最近不少读者私信问我一个问题:个人开发者到底能不能跑通 LLM 的完整链路?这里说的完整链路,不只是用开源的 ChatGLM、Qwen 或 LLaMA 做做推理,而是从数据准备、词表训练、预训练、领域继续训练,再到 SFT、偏好对齐、检…

阅读更多 →
Claude Code 安装后自动更新报错?用 TaoToken 统一 Key 排查配置与运行环境 2026/9/29 6:57:01

Claude Code 安装后自动更新报错?用 TaoToken 统一 Key 排查配置与运行环境

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

阅读更多 →
AI工程化从零到一:构建机器学习流水线的完整实践指南 2026/9/29 6:57:00

AI工程化从零到一:构建机器学习流水线的完整实践指南

1. 从模型到系统:AI工程化到底在解决什么问题这两年“AI工程”这个词被反复提起,但真正能讲清楚它是什么的人并不多。我见过太多团队拿着训练好的模型,却卡在上线前的最后一公里:模型在离线评测集上跑得挺好,一上生产就…

阅读更多 →
炸裂!用TaoToken统一Key接入DeepSeek/豆包/元宝,AI论文平台配置一次跑通 2026/9/29 6:57:00

炸裂!用TaoToken统一Key接入DeepSeek/豆包/元宝,AI论文平台配置一次跑通

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

阅读更多 →
事后经验回放(HER):破解稀疏奖励难题的强化学习利器 2026/9/29 6:56:59

事后经验回放(HER):破解稀疏奖励难题的强化学习利器

拿到“hindsight”这个项目名时,我脑子里第一时间蹦出来的是那句老话:事后诸葛亮,人人都能当。但真把这个词放到技术语境里,它其实指向一种非常有价值的能力——让系统在事情发生之后,通过回看轨迹、重新解读失败&…

阅读更多 →
TensorFlow工程实战:安装避坑、机制解析与生产部署要点 2026/9/29 6:56:59

TensorFlow工程实战:安装避坑、机制解析与生产部署要点

1. 先别急着站队:TensorFlow与PyTorch背后的生态博弈最近接手一个项目,客户的算法原型是用PyTorch训练的,生产部署却明确要求TensorFlow。迁移过程中,我把TensorFlow的安装、数据管线、模型训练、导出整条链路重新走了一遍&#x…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉