devshell - 类似 virtualenv，但适用于所有语言

状态：不稳定

本项目的目标是简化每个项目的开发者环境。

想象一下，一名新员工加入公司，或者有人转组，又或者 有人想为你的某个开源项目做出贡献。他们应该能在 10 分钟内克隆仓库并获取所有开发依赖项。

文档

参见 docs (docs source)

特性

兼容性

保持与以下工具兼容：

• nix-shell
• direnv
• nix flakes

干净的环境

pkgs.stdenv.mkDerivation 和 pkgs.mkShell 构建于 pkgs.stdenv 之上，后者引入了各种依赖项。每个添加的包， 例如“Story time!”部分中的 pkgs.go，都有可能引入 新的环境变量，而这些变量随后需要被取消设置。stdenv 本身 包含 GCC 或 Clang，这使得选择特定的 C 编译器变得困难。

这就是为什么 mkShell 从一个 builtins.derivation 构建其环境。

direnv 加载将变为：

direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +HOST_PATH +IN_NIX_SHELL +LD +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_BUILD_CORES +NIX_BUILD_TOP +NIX_CC +NIX_CC_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_CFLAGS_COMPILE +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_INDENT_MAKE +NIX_LDFLAGS +NIX_STORE +NM +OBJCOPY +OBJDUMP +RANLIB +READELF +RUSTC +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +TEMP +TEMPDIR +TMP +TMPDIR +buildInputs +buildPhase +builder +builtDependencies +cargo_bins_jq_filter +cargo_build_options +cargo_options +cargo_release +cargo_test_options +cargoconfig +checkPhase +configureFlags +configurePhase +cratePaths +crate_sources +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +docPhase +dontAddDisableDepTrack +dontUseCmakeConfigure +installPhase +name +nativeBuildInputs +out +outputs +patches +preInstallPhases +propagatedBuildInputs +propagatedNativeBuildInputs +remapPathPrefix +shell +src +stdenv +strictDeps +system +version ~PATH

to:

direnv: export +DEVSHELL_DIR +PRJ_DATA_DIR +PRJ_ROOT +IN_NIX_SHELL +NIXPKGS_PATH ~PATH

有一些新的环境变量，可用于支持日常 活动：

• DEVSHELL_DIR：包含所有程序。
• PRJ_ROOT：指向项目根目录。
• PRJ_DATA_DIR：默认指向 $PRJ_ROOT/.data。用于存储运行时数据。
• NIXPKGS_PATH：nixpkgs 源码的路径。

常用工具

Shell 预加载了一些实用函数。我不确定 它们目前是否真的有用：

• menu - 列出所有可用的程序

MOTD

当进入一个随机项目时，快速查看可用的 命令是很有用的。

当运行 nix-shell 或 nix develop 时，mkShell 会打印一条欢迎消息：

🔨 Welcome to devshell

[[general commands]]

  hello         - prints hello
  menu          - prints this menu

[formatters]

  nixpkgs-fmt   - Nix code formatter for nixpkgs

[linters]

  golangci-lint - golang linter

[utilites]

  hub           - github utility

[devshell]$ 

可通过 TOML 文件进行配置

你可能对 Nix 充满热情，但团队中的其他人可能害怕这种非主流技术。因此，让他们编写 TOML 吧。它应该能处理 80% 的使用场景，并且始终可以回退到 Nix。

默认启用 Bash 补全

否则生活就不完整了。呵呵。

包含 bash 补全的包将在 nix-shell 或 nix develop 模式下由 mkShell 自动加载。

在 CI 中捕获开发依赖项

在 CI + 二进制缓存设置中，人们通常希望能够捕获 shell.nix 的所有构建输入。使用 mkShell 捕获所有开发依赖项非常简单：

nix-build shell.nix | cachix push <mycache>

作为 Nix 应用程序运行

Devshells 是可运行的（通过 nix run）。 这使得无需进入 nix-shell 或 nix develop 会话即可运行 devshell 中定义的命令：

nix run '.#<myapp>' -- <devshell-command> <and-args>

本项目本身暴露了一个 Nix 应用程序；你可以使用以下命令进行试用：

nix run 'github:numtide/devshell' -- hello

参见此处]以获取更多详细信息。

待办事项

很多事情！

• 文档
  • 解释所有这些机制的工作原理以及所有使用场景。
• 测试
  • 为所有使用场景编写集成测试。
• 惰性依赖
  • 这需要与仓库结构进行一些协调。为了保持 开发闭包较小，能够按需加载部分 依赖项将是很好的。
• Doctor / nix 版本检查
  • 并非所有事情都能被完美地沙箱化。是否可能获取一个快速的 doctor 脚本来检查一切是否处于良好状态？
• 支持其他 shell
  • 什么？不是每个人都在使用 bash？目前，在 direnv 模式下已经提供了支持。

贡献

文档

1. Change files in docs/
2. Run nix run .#docs
3. Open docs

基准测试

1. See benchmark/README.md
2. Run nix run .#bench

商业支持

正在寻找帮助或定制？

联系 Numtide 获取报价。我们让企业轻松与开源项目合作：https://numtide.com/contact