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

Question

我是一个关于 hackage 的包的维护者，lrucache。我最近收到了一个为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）或多或少是你现在拥有的。然后，如果人们想要最小化他们的依赖关系，他们会使用精简版，如果他们不关心有无数的依赖关系，他们会使用标准版本。大的可能会依赖精简的，以避免代码重复。

Answer 3

游戏有点晚了，但我的两分钱：

1. 库的公共 API（包括类实例）永远不应根据构建标志或包可用性而更改 - 它会惩罚下游开发人员和发行包维护者。

2. 我将毫无疑问地向 Haskell 平台中的任何内容添加依赖项（可能除了“unix”或“win32”等）。

这仍然是“二进制”，但是根据其 Hackage 页面，它可以在多个 Linux 发行版中使用，并且根据我的经验，它可以在 Windows 上干净地安装。在这种情况下，我会接受补丁，但不会自己编写。

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

Answer 4

我可以向 lrucache.cabal 添加标志，以便编译各种 实例。就使依赖项列表最小化而言，这是有效的， 除非你想要它。但这在现实世界中很可怕，因为 您不能在 build-depends 部分中指定构建标志。这样你就可以 依赖于具有特定标志的包，但未指定 依赖。这很快就会变得几乎无用。

这可能正是您所说的不适用于上面的内容，但是您可以在conditionally-compiled CPP 编译指示中包含您的导入和类定义吗？我想包裹在imports 的内部模块中，这些模块又会导入您的“可选依赖项”之一。

我还没有尝试过，但我也很想知道答案。