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