安装的 Composer 模块是否独立于操作系统？答案

【问题标题】：Are installed Composer modules OS independent?安装的 Composer 模块是否独立于操作系统？
【发布时间】：2018-08-31 21:25:41
【问题描述】：

我知道下面的场景与现代最佳实践相去甚远，但让我们试一试。

假设：

您的开发环境和服务器具有相同的 PHP 版本，但操作系统不同。
您希望/必须将您的供应商文件夹按原样部署到服务器。

这有多大可能：某些软件包由于操作系统切换而无法工作，如果它们是从服务器上的 composer json 文件安装的，则可以避免失败（即它们不完全依赖于平台）？

我从这个question 知道安装期间设置的绝对路径可能是个问题。还有其他可能的问题吗？

【问题讨论】：

经验证据：概率为 100%。你在问题中说让我们试一试，这是公平的。但是现在绝对没有理由再出现这样的问题了，因为 vagrant 和 docker 广泛可用且易于使用。

标签： php composer-php devops

【解决方案1】：

这种可能性非常高，因为作曲家的工作方式会因环境设置而异。

这个简单的例子是https://getcomposer.org/doc/articles/scripts.md

它可以根据已安装的组件运行自定义逻辑，并且只有在主机操作系统有可用的东西时才准备一些东西——这与 composer.lock 无关

核心问题是你想重用供应商文件夹。 Composer 不是以这种方式工作的，这就是为什么在 .gitignore 文件中经常提到 vendor 的原因。作曲家将在每个环境中表现不同，并且不应复制其结果。如果您想让 OS-es 之间的行为保持一致，请使用 Docker 或 vagrant 来稳定应用程序及其环境。

【讨论】：

请注意，实际复制供应商文件夹有一些正当理由：codeenigma.com/build/blog/…。我一直这样做，因为它可以让我完全控制我的依赖关系。
@Loek 这些都不是正当理由，它主要是为自己的懒惰和无法在单独的依赖项上使用git diff 寻找理由。 :)
@janmyszkier 是否有“composer 的工作方式因环境设置而异”的示例？ composer.lock 的重点是创建 composer install 的可预测结果，无论环境如何。
嗯，我不太同意。但我明白了，只是指出没有“完美的 Composer 工作流程”之类的东西
@Loek 也许不是，但版本控制vendor 目录尽可能远离完美的工作流程。您想如何区分开发环境（具有大量开发依赖项）和生产环境？您希望如何浏览里程碑之间的差异（其中 90% 的更改来自供应商）？更不用说解决vendor目录中的冲突了。 :D 如果您认为版本控制 vendor 会简化您的工作流程，那么您确实需要做错事。

【解决方案2】：

只要您将composer.lock 提交到您的项目中，它们就应该独立于操作系统。 composer.lock 的重点是通过独立于操作系统的composer install 安装相同的包，并且 Composer 本身不使用任何绝对路径（默认情况下）。事实上，Composer 维护者discourage using it in production 和许多问题都以“Composer 不是部署工具”为理由而关闭。因此，按照设计，您应该能够在环境之间移动安装，并且在每个系统上，您将获得composer install 安装的相同软件包。

唯一的问题可能来自scripts 和/或plugins，它们可能会做一些不可移植的事情，您需要在目标安装上运行它。

简而言之：是的，安装独立于操作系统（除非您做某事，否则会改变这一点）。

【讨论】：

为了 100% 清楚：“安装”是指在每个环境中单独安装，而不是将已安装的软件包从一个地方移动到另一个地方。简而言之：'已经安装的包可以（并且可能会）依赖于环境（即传输后可能会失败）'。
不，完全相反 - 已经安装的软件包很可能不会依赖于环境，您应该能够在不同的环境之间移动 vendor directory 而不会有任何麻烦。 “安装”是指完整的应用程序（应用程序代码 + 由 composer install 安装的 vendor 目录中的所有依赖项） - 您应该能够将此类包部署到任何环境（只要满足要求 - PHP 版本和已安装的扩展）无需在其上运行作曲家。