如何处理添加新包依赖项的功能请求

Question

我是hackage包{@ 3}}的维护者。我最近收到了添加Binary和NFData实例的功能请求。这些都是有用的东西，原则上我对这些实例没有任何问题。

但是，它们都引入了新的包依赖关系，我希望尽可能减少我的包的依赖列表。有理智的方法来处理这个问题吗？可能有超过20个不同的包提供lrucache中的数据结构可以实现的有用类型类，并从中获益。

显然，将所有这些作为依赖项添加是一个非首发。但还有什么可以做呢？

我可以向lrucache.cabal添加标志，以便编译各种实例。这样做可以使依赖列表最小化，除非您需要它。但它在现实世界中是可怕的，因为你无法在build-depends部分中指定构建标志。因此，您可以依赖具有特定标志的包，但不指定该依赖关系。这很快就会减少到无用之中。

我可以创建一堆孤立实例包。这样做的好处是可以在build-depends部分中指定对这些实例的依赖性。它的主要缺点是为hackage添加了大量的额外包装，并且需要将它们作为单独的包装进行维护。

我还能做什么？什么是正确的做法？

Answer 1

缺少cabal（包装系统）本身的可选依赖系统，选项不太好。

一个选项如下。您可以为可能希望主程序包集成的每个附加程序包创建自己的附加程序包。

例如，如果您希望lrucache与binary集成，则可以创建包含集成的其他包lrucache-binary（在本例中为类型类实例）。同样，您自己lrucache-nfdata的新软件包可以将lrucache与nfdata集成。

然后，如果有人希望lrucache及其与binary的整合，他可以依赖[binary, lrucache, lrucache-binary]。

Answer 2

如果你只维护两个软件包怎么办：lrucache，这取决于很多不同的东西，然后是lrucache-lite（或lrucache-minimal），这或多或少是你现在拥有的。然后，如果人们想要最小化他们的依赖关系，他们使用lite版本，如果他们不关心拥有多个依赖关系，他们使用标准版本。最大的一个可能取决于精简版，以避免代码重复。

Answer 3

比赛有点晚了，但我的两分钱：

1. 库公共API（包括类实例）永远不应该根据构建标志或软件包可用性进行更改 - 这对于下游开发人员和发行版软件包维护者来说是一种惩罚。

2. 我会毫无疑问地向Haskell平台中的任何内容添加一个依赖项（除了'unix'或'win32'之外）。

仍然留下'二进制'，但是根据它的Hackage页面，它可以在多个Linux发行版中使用，根据我的经验，在Windows上安装得很干净。在这种情况下，我会接受一个补丁，但不是自己创作。

这并不能直接回答这个问题，但希望能说明我会使用的思考过程。

Answer 4

  

我可以在lrucache.cabal中添加标志，以便编译各种文件   实例。这有助于使依赖列表最小化，   除非你想要它。但它在现实世界中很可怕，因为   您不能在build-depends部分中指定构建标志。所以你可以   依赖于具有特定标志的包，但不指定   依赖。这很快就会减少到无用之中。

这可能正是您所说的对您不起作用，但您可以在conditionally-compiled CPP pragma中包含导入和类定义吗？我想包裹imports内部模块，然后导入一个“可选依赖项”。

我没有试过这个，但我也非常有兴趣知道答案。