我想在我的应用程序中同时使用 Phing 和 Composer。Phing 作为构建系统和 Composer 来管理依赖项。但是应该以哪种方式使用它们？
目前，我们正在所有服务器上全局安装 Phing。Phing 应该完全自动化我们各种项目的构建。只需签出项目的副本，使用默认目标运行 Phing，您应该会很好。这也意味着那里应该有一个 Phing 目标，它调用 Composer 来安装所有依赖项。所以，Phing 调用作曲家。但是我一直找不到有关此设置的任何信息。没有 ComposerTask 或任何类似的东西，谷歌搜索并没有发现任何人以这种方式工作。
但我确实看到了很多相反的情况。人们使用 Composer 将 Phing 安装为项目依赖项。
那么，每种方法的（缺点）优点是什么？我是否试图以错误的方式做到这一点？
我认为通过 composer 安装 phing 的主要优势在于，对于开源项目，更容易确保您的用户以这种方式安装了 phing。通常在这些设置中，phing 只是某些库用来完成某些任务的工具。
另一个优点是每个项目都可以使用不同版本的 phing，如果你有一个系统范围的版本，你就无法做到这一点。
如果您使用 phing 来管理您的整个项目构建/设置，则从中调用 composer 可能是有意义的，但反过来也是如此。例如，您可以在每次依赖项更新后使用 composer脚本来触发 phing 任务。这样，项目设置将是：
老实说，我不知道是否有正确的答案。您可以使两种方式都起作用，但是通过这种方式，您至少可以避免必须先安装 phing。显然，您需要安装 composer，但可以说这更容易，而且无论如何您都需要它。
关于这个主题的其他想法。
一般来说，塞尔达克是对的，两者都是可能的。不过，也有关于 phing 的争论。在构建架构的层面上，我认为首先作曲家没有意义。构建过程具有更广泛的范围和更长的生命周期，因此应该管理依赖管理器，反之亦然。
此外，如果您使用 Phing 令牌替换来确定要在哪个环境中安装哪些依赖项版本，那么首先使用 composer 几乎是不可能的，因为 phing 将生成 composer.json，因此必须在 composer 可以运行之前安装。