Nix项目中导入路径符号链接解析的回归问题分析

问题背景

在Nix项目版本迭代过程中，2.19.8版本与2.27版本在处理导入路径符号链接解析时出现了行为差异。具体表现为当使用nix eval命令评估特定flake时，不同版本会生成不同的派生路径(drvPath)。这一变化源于底层对符号链接解析逻辑的修改。

技术细节

在Nix 2.19.8及更早版本中，系统通过checkSourcePath()函数处理路径解析，该函数会根据是否启用纯净模式(pure mode)来决定是否解析符号链接。具体表现为：

• 纯净模式下：解析符号链接
• 非纯净模式下：保留原始符号链接路径

而在2.27版本中，这个函数被移除，导致符号链接解析行为变得一致，不再区分纯净模式。这一变化影响了构建过程中源路径(sourceRoot)的最终表现形式：

• 2.19版本：生成类似source/./tests/functional的路径
• 2.27版本：生成类似source/./src/nix-functional-tests的路径

影响分析

这种变化实际上修正了2.19版本中存在的不一致行为。在2.19版本中，纯净模式与非纯净模式下会产生不同的构建结果，这违背了构建系统应保持确定性的基本原则。2.27版本通过统一符号链接解析行为，确保了构建过程在不同环境下的结果一致性。

解决方案讨论

虽然可以通过修改primops.cc中的import函数实现类似2.19版本的行为（根据纯净模式决定是否解析符号链接），但Nix开发团队经过讨论后决定保持2.27版本的行为，原因如下：

1. 构建系统应保持确定性，不应因纯净模式设置而产生不同结果
2. 2.19版本的行为实际上是一个设计缺陷
3. 统一符号链接解析行为更符合Nix的设计哲学

结论

这一变化虽然表面上看起来是一个"回归"问题，但实际上是对系统行为的合理修正。开发者在使用Nix构建系统时应当注意：

1. 避免依赖符号链接解析行为在不同模式下的差异
2. 确保构建过程在不同环境下具有一致性
3. 理解Nix对构建确定性的严格要求

对于确实需要保留符号链接的场景，可以考虑其他解决方案，如明确指定路径或调整项目结构，而不是依赖构建系统的隐式行为。