Stack项目Windows平台脚本执行回归问题分析

问题背景

在Stack 2.13.1版本中，Windows平台上使用stack script命令执行Haskell脚本时出现了一个回归问题。具体表现为当切换解析器版本后，预编译包无法正确注册到包数据库中，导致脚本执行失败。这个问题在Linux平台上不存在，是Windows特有的行为。

问题现象

考虑一个简单的Haskell脚本示例：

{- stack script
   -- resolver lts-21.24
   -- package acme-missiles
-}

import Acme.Missiles

main :: IO ()
main = launchMissiles

在Stack 2.11.1版本中，无论是首次执行还是切换解析器版本后，都能正常工作。但在Stack 2.13.1版本中，切换解析器版本后会出现以下错误：

ghc-pkg-9.8.4.exe: D:\sr\snapshots\90c0b32b\pkgdb\package.cache.lock: openBinaryFile: resource busy (file is locked)

问题分析

通过深入调试和分析，发现问题的根源在于Windows平台上ghc-pkg命令对包数据库锁文件package.cache.lock的处理方式存在差异。

关键发现

1. 环境变量差异：stack script命令会设置GHC_PACKAGE_PATH环境变量，而普通的stack build命令不会。这个环境变量的设置似乎触发了ghc-pkg的锁文件问题。

2. 锁文件行为异常：在Windows平台上，ghc-pkg在执行注册操作时无法正确获取锁文件，即使文件实际上未被其他进程锁定。这种问题在Linux平台上不会出现。

3. 手动执行成功：有趣的是，在调试过程中手动执行相同的ghc-pkg register命令可以成功，但通过Stack的RIO.Process.proc调用时就会失败。

技术细节

当Stack执行脚本时，会经历以下关键步骤：

1. 卸载旧版本的包
2. 尝试注册新版本的包
3. 查询包数据库验证注册结果

问题出现在第二步，ghc-pkg无法获取包数据库的锁文件，导致注册失败。即使引入120秒的延迟或手动删除锁文件，问题依然存在。

解决方案

Stack团队已经通过提交修复了这个问题。修复的核心思路是：

1. 改进Windows平台上包数据库锁文件的处理逻辑
2. 优化ghc-pkg命令的调用方式
3. 确保在注册操作前包数据库处于可写状态

结论

这个案例展示了跨平台开发中的常见挑战——同一行为在不同操作系统上的表现可能大相径庭。Windows平台对文件锁的处理方式与Unix-like系统有显著差异，开发工具需要特别处理这些差异才能保证跨平台兼容性。

对于Haskell开发者来说，遇到类似问题时可以：

1. 检查包数据库的权限状态
2. 验证锁文件是否被正确释放
3. 考虑临时禁用环境变量进行测试
4. 关注工具链的版本更新，及时应用修复

Stack作为Haskell生态中的重要工具，其跨平台兼容性的持续改进对开发者体验至关重要。这个问题的修复再次体现了开源社区对Windows平台支持的重视。