zh/best-practices/accelerating-dotfiles-debugging

[giscus[bot]]

zh/best-practices/accelerating-dotfiles-debugging

一份非官方的新手指南

https://nixos-and-flakes.thiscute.world/zh/best-practices/accelerating-dotfiles-debugging

[kmjuq]

我用了创建软链接的方法没起效果呀，修改原文件，软链接文件没有同步修改，然后用nix-darwin创建的软链接是root，nixbld，登陆用户没有权限访问配置文件，请问这里有啥问题吗？

[ryan4yin]

哦我知道你为什么失败了，你用了 self.outPath，这是一个 /nix/store 里的地址，那肯定不会有效。

[ryan4yin]

有个关键点是，我教程里说的 假设你将你的 Neovim 配置放在了 ~/nix-config/home/nvim 下，然后后面给的 nix 配置也是直接使用了这个位置的绝对路径。
如果你无法明确你会把你的 nix 配置放在哪里，那这个方法是用不了的。

[kmjuq]

主要是不想固定nix-config的项目路径，因此想拿到当前flake.nix文件的路径，然后通过这个路径找到全路径。

[kmjuq]

我是模块注入的self变量都没，弄不懂这个变量怎么传递的，通过specialArgs {inherit intpus;}，在imports属性导入的时候，nix脚本也拿不到解构的变量，然后因为想动态根据设备来生成input和output，就调整整体结构了，就没管这个了。现在是无法使用状态，哈哈。

[ryan4yin]

主要是不想固定nix-config的项目路径，因此想拿到当前flake.nix文件的路径，然后通过这个路径找到全路径。

为了确保可复现能力，Nix 中所有的文件路径都是指向 Nix Store 的，所以你的想法注定无法实现。

NixOS 的部署流程是：

1. 把完整的配置复制到 Nix Store 中.
2. 接着使用 Nix Store 中的配置进行所有后续计算与部署操作.

也就是说你的配置到底放在了哪里，从第二步开始，Nix 就完全不清楚该信息了，自然你在 nix 配置中也不可能拿得到这个信息。

[segment-tree]

所以mkOutOfStoreSymlink是不支持递归创建链接的吗？

[kmjuq]

不是一回事，可以的

[merrkry]

这个东西引入了很强的 impurity。既然不依赖 Nix 编排，那么用 chezmoi, stow 这类专门的 dotfiles 管理器体验更好，还不用吃 Nix eval 慢的苦。

[kmjuq]

不是不依赖编排，像neovim等软件的配置信息经常要动，正常管理方式导致要一直重建，使用mkOutOfStoreSymlink可以直接改配置文件，就不用重建了，重建很浪费时间也没必要，我现在是通过添加项目的参数nix脚本，然后在build的时候通过命令修改nix参数脚本。

[kmjuq]

chezmoi等软件没深入了解过，在不同硬件上不同操作系统上的不同路径，它处理方便吗？nix的配置管理可以比较自由的映射路径

[ryan4yin]

得看用法了，我绝大部分软件都是用 home-manager 声明式配置的，只有 neovim emacs 等个别软件是用的 mkOutOfStoreSymlink, 这个场景下我觉得 mkOutOfStoreSymlink 要比再引入一个 chezmoi stow 啥的要简单实用的多。

[ryan4yin]

还有我的 hyprland 配置是两种方式都有用到的，大部分配置是通过 mkOutOfStoreSymlink 链接到指定位置并且支持 auto reload，而显示器配置等每台机器都有不同的内容，则通过 Nix 来声明，Nix 的声明式配置中会使用 include 引入其他非 Nix 声明的配置。

这种场景下如果把需要 mkOutOfStoreSymlink 的部分拆到 chezmoi, 感觉是把问题复杂化了。