Haskell Cabal单未命名库限制原因及多模块依赖处理咨询

1. 单未命名library限制是临时措施还是必要要求？ #

这不是临时措施，而是Haskell包构建模型的必要设计。Cabal和Hackage的包模型核心逻辑是：一个包对应一个核心的未命名库（即默认的library stanza），这是包对外提供的主要接口。依赖解析工具（Cabal、Stack）都是基于包级别进行版本管理和依赖追踪的，每个包的主库身份是唯一的，这一设计保证了包生态的一致性和依赖解析的可预测性，不会被移除。

2. 避免多暴露模块共享全部依赖的可行方案 #

• 使用命名内部库（Internal Libraries）：在.cabal文件中定义多个带名称的library stanza（比如library core、library utils），每个内部库可以单独指定build-depends、exposed-modules（内部库的模块默认不对外暴露，除非主库依赖并重新导出）。主库只需要依赖这些内部库，并对外暴露需要的模块，这样不同的暴露模块可以对应不同的内部库，实现依赖隔离。
• 条件编译+标记（Flags）：通过定义Cabal标记（比如flag use-feature-a），给不同模块设置条件化的依赖。比如当启用某个标记时，引入对应模块的依赖，适合依赖差异和功能开关绑定的场景，但灵活性不如内部库。
• 拆分私有模块：将不需要对外暴露的模块设为other-modules，只保留核心暴露模块在exposed-modules中，主库的build-depends仅保留所有暴露模块的共同依赖，私有模块的额外依赖如果不影响对外接口，可以放在主库中，但这种方式只能减少冗余依赖，无法完全隔离不同暴露模块的依赖。

3. 部分共同依赖的暴露模块，避免拆分多包的推荐操作 #

最推荐的方式是使用内部库拆分依赖：

1. 把两个暴露模块分别放到两个命名内部库中，每个内部库声明自己的build-depends（包含各自的独有依赖和共同依赖）；
2. 可以额外抽一个内部库来存放两者的共同依赖模块，让两个业务内部库依赖这个共同内部库，进一步复用代码和依赖；
3. 最后在主库（未命名library）中依赖这两个业务内部库，并通过exposed-modules重新导出需要对外暴露的模块。

这种方式不需要拆分多个独立包，所有代码和依赖管理都在同一个.cabal文件中完成，既实现了依赖隔离，又保持了对外接口的统一性。

内容的提问来源于stack exchange，提问作者Enlico