我是hackage包的维护者，lrucache . 我最近收到了为 Binary 和 NFData 添加实例的功能请求 . 这些都是有用的东西，原则上我对这些实例没有任何问题 .
但是，它们都引入了新的包依赖关系，我希望尽可能减少我的包的依赖列表 . 有理智的方法来处理这个问题吗？可能有超过20个不同的包提供了 lrucache 中的数据结构可以实现的有用类型类，并从中获益 .
显然，将所有这些作为依赖项添加是非启动性的 . 但还有什么可以做呢？
我可以向lrucache.cabal添加标志，以便编译各种实例 . 这样做可以使依赖列表最小化，除非您需要它 . 但它在现实世界中是可怕的，因为你无法在build-depends部分中指定构建标志 . 因此，您可以依赖具有特定标志的包，但不指定该依赖关系 . 这很快就会减少到无用的程度 .
我可以创建一堆孤立实例包 . 这样做的好处是可以在build-depends部分中指定对这些实例的依赖性 . 它的主要缺点是在hackage中添加了大量额外的包，并且需要将它们作为单独的包维护 .
我还可以做些什么？什么是正确的做法？
4 回答
如果你只维护两个软件包：
lrucache，这取决于很多不同的东西，然后是lrucache-lite（或lrucache-minimal），这或多或少是你现在拥有的 . 然后，如果人们想要最小化他们的依赖关系，他们使用lite版本，如果他们不关心拥有多个依赖关系，他们使用标准版本 . 最重要的可能取决于精简版，以避免代码重复 .如果没有cabal（包装系统）本身的可选依赖系统，那么选项就不太好了 .
一种选择如下 . 您可以为要与主程序包集成的每个附加程序包创建自己的附加程序包 .
例如，如果您希望
lrucache与binary集成，则可以创建包含集成的附加包lrucache-binary（在本例中为类型类实例） . 同样，你自己的一个新包lrucache-nfdata将lrucache与nfdata整合在一起 .然后如果有人想要
lrucache和它与binary的整合，他可以一起依赖[binary, lrucache, lrucache-binary].游戏有点晚了，但我的两分钱：
库公共API（包括类实例）永远不应该根据构建标志或软件包可用性进行更改 - 这对于下游开发人员和发行版软件包维护者来说是一种惩罚 .
我会毫无疑问地向Haskell平台中的任何内容添加一个依赖项（除了'unix'或'win32'之外） .
这仍然是“二进制”，但根据其Hackage页面，它可以在多个Linux发行版中使用，根据我的经验，在Windows上安装得很干净 . 在这种情况下，我会接受一个补丁，但不是自己创作 .
这并没有真正直接回答这个问题，但希望能够说明我将使用的思维过程 .
这可能正是您所说的对您不起作用，但您可以在conditionally-compiled CPP pragma中包含您的导入和类定义吗？我想包裹着
imports的内部模块，这些内部模块又会导入你的一个"optional dependencies" .我没有试过这个，但我也非常有兴趣知道答案 .