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