2011-09-15 20 views
15

我是hackage上的程序包的维护人员,lrucache。我最近收到了为BinaryNFData添加实例的功能请求。这些都是有用的东西,原则上,我对这些实例没有任何问题。如何处理添加新程序包相关性的功能请求

但是,它们都引入了新的包依赖关系,并且我想尽可能地减少包的依赖关系列表。有一个理智的方式来处理这个问题吗?可能有超过20种不同的包提供有用的类型类,lrucache中的数据结构可以实现,并从中受益。

显然,将它们全部添加为依赖关系是一个非启动器。但还有什么可以做的?

我可以将标志添加到lrucache.cabal中,以便编译各种实例。这可以起到最小化依赖列表的作用,除非你需要。但是在现实世界中这很可怕,因为你不能在依赖build的部分中指定构建标志。因此,您可以依赖具有特定标志的包,但不指定该依赖关系。这很快就会降低到接近无用的程度。

我可以创建一堆孤儿实例包。这具有允许在依赖于构建的部分中指定对这些实例的依赖性的优点。它的主要缺点是增加了大量额外的软件包,并需要将它们作为单独的软件包进行维护。

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

+2

至少,“孤立实例包”方法似乎是一种常见策略。正确的做法可能是创造更好的依赖管理,但是...... –

+1

@C。 A. McCann,当我使用'./configure --enable-Z'时,我个人不喜欢它。我喜欢简单的事情 - 安装标记为已安装的软件包,而不是“它安装了选项X和Y但不是Z”。也许Hackage可以更好地组织孤立实例包,但我认为它们在概念上并不合法。 – gatoatigrado

+0

@gatoatigrado:我同意。像我提到的那样,Cabal更好地组织它们也可以称为“更好的依赖管理”,所以请随时发明它。 :]我不确定实施这样的系统会遇到什么障碍。 –

回答

7

在cabal(包装系统)本身缺少可选的依赖关系系统,这些选项不太好。

一个选项如下。您可以为每个可能希望主要软件包集成的附加软件包创建一个自己的附加软件包。例如,如果您希望lrucachebinary集成,您可以制作一个包含集成(本例中为类类实例)的附加包lrucache-binary。同样,您自己的新套装lrucache-nfdatalrucachenfdata集成。

然后,如果有人想要lrucache及其与binary的整合,他可以依靠[binary, lrucache, lrucache-binary]在一起。

+0

这正是我提到的“孤儿实例包”的东西,我想。 – Carl

3

如果你只是维护两个包:lrucache,这取决于几十万个不同的东西,然后lrucache-lite(或lrucache-minimal),这或多或少是你现在拥有的东西。然后,如果人们想要最小化他们的依赖关系,他们使用精简版,如果他们不关心拥有数亿依赖关系,他们使用标准版本。大的可能会依赖于精简版,以避免代码重复。

+0

我已经看到这个名称为'lrucache'和'lrucache-instances'。这样只有两个软件包,但没有选择实例的能力。 –

0

我可以将标志添加到lrucache.cabal中,以便编译各种 实例。这可以起到最小限度的依赖列表 的作用,除非您需要。但是在真实世界中它很糟糕,因为 你不能在依赖build的部分指定构建标志。所以你可以用 依赖于一个包含特定标志的包,但不能指定 的依赖关系。这很快就会降低到接近无用的程度。

这可能正是你所说的不适合你的,但是你可以在conditionally-compiled CPP编译指示中包含你的导入和类定义吗?我想应该包含内部模块的imports,然后导入你的“可选依赖项”。

我还没有尝试过这种方法,但对于了解答案也非常感兴趣。

+0

是的,这有效。但让我们说,我做了它,例如,一个二进制实例。假设您正在编写一个使用lrucache的程序,并且想要使用Binary实例对其进行序列化。无法在cabal文件的build-depends部分中指出该方法。这是这种方法的问题。 – Carl

1

有点晚了比赛,但我的两分钱:

  1. 一个图书馆的公共API(包括类的实例)应该永远不会改变基础上构建的标志或包装的可用性 - 这是在惩罚的向下流开发人员和发行版软件包维护人员。

  2. 我会毫无疑问的添加一个依赖项到Haskell Platform中的任何东西(除了'unix'或'win32'之类的东西)。

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

这并不是直接回答这个问题,而是希望能够说明我会使用的思维过程。