如何在我的私人存储库中获取包含包的确切版本答案

【问题标题】：How to get the exact version of included packages in my private repository如何在我的私人存储库中获取包含包的确切版本
【发布时间】：2020-11-19 04:45:04
【问题描述】：

我目前正在试用 Satis。我希望能够在某个地方获得我的私有包的确切版本，所以通常在 composer.lock 中的所有内容。我总是通过 Git 提交 composer.lock。

但如果我理解正确的话，它的 packages.json 中的 Satis 总是只包含需要的部分，即我的 composer.json 中的部分，因此当然只有版本范围。

有没有办法配置 Satis 以便也存储 composer.locks 或者我如何获得我的包的确切“快照”？

+++ 示例 +++

好的，我试着解释一下。

假设我有一个包 my/package。这里我添加了几个文件，包括 composer.json，我在其中定义了 symfony/console 应该安装在大于或等于 4 的版本中。现在我执行“composer install”，并且 Symfony 安装在 4.4 版本中。我提交所有文件，包括 composer.lock 并创建一个版本 1.0。

现在我要去萨蒂斯。在这里，我将 my/package 和 my/package 的相应存储库 URL 添加到 satis.json 并更新它。 Satis 正确地检查了我的包，并在 packages.json 或更准确地说是 all*.json 我的包在 1.0 版中列出。到目前为止一切都很好。

但是，如果我现在看一下 Satis 在 all*.json 中为我的包存储的元数据，我会发现这里实际上是我指定的要求，即 symfony/console 应该安装在大于或等于 4 的版本中. 所以 Satis 拍摄了 composer.json 的快照，显然忽略了 composer.lock。所以我没有机会看到我的版本 1.0 与 Symfony 的确切版本 4.4 一起使用，而例如版本 1.1 与 symfony/console 4.5 一起使用。但这些信息对我来说很有趣。

【问题讨论】：

你想在哪里存储任何东西？ Composer 仅读取来自 Satis 的包，不存储任何内容
即我打电话给example.com/packages.json 并解析它。
听起来不错 - 解析该包文件有什么问题？
问题是没有版本号。 Satis 似乎只保存了需求，而不是实际安装的版本，我很想知道它们。
如果您的包的 1.1 版适用于 symfony/console 4.5 而不适用于 symfony/console 4.4，您应该更新包的 composer.json 中的约束。这就是约束点——它为依赖项提供了版本范围。范围越广，您最终出现依赖冲突的可能性就越小。使用来自composer.lock 的精确版本基本上可以保证冲突，因为每个包都可能有一些细微的差异。

标签： php composer-php

【解决方案1】：

所以，我现在构建了一个解决方法。整个事情并不是很完美，因为大型存储库的运行时间相对较长，这就是为什么我必须每天将它作为 cron 运行一次。但它工作正常。

我创建了一个新的 Satis 控制台命令。
此命令使用 PackageSelection 类来确定所有现有的包。
我遍历包列表并查找 dist 文件的路径和名称。
我在内存中提取 ZIP 文件并查找 composer.lock。如果有，我会解析它并读取依赖包的确切版本号。
我将信息汇总在一个单独的 JSON 文件中，并将其与 htdocs 下的 packages.json 并行存储。从那里我可以调用它并将其集成到我自己的应用程序中或进一步处理它。

【讨论】：

【解决方案2】：

安装包时，Composer 会即时重新计算所有依赖项。这是基于您的应用程序的composer.json 和所有依赖项的composer.json 文件。

composer.lock 不应该是任何包的一部分，并且在安装包时不考虑在内。

【讨论】：

你可以在你的包中包含composer.lock（它通常很有用），当你作为依赖安装这个包时它不会被使用。
@rob006 你能分享一些有用的例子吗？我刚刚查看了一些软件包（Symfony、Laravel、Guzzle、Google 的 API 客户端 SDK、PHPUnit），但这些存储库都没有列出它们的锁定文件。在热门包列表中搜索，Doctrine 人是我第一个找到锁文件的地方
@rob006 把它放在一个单独的问题中，我已经打开了stackoverflow.com/questions/63214966 - 我很高兴收到你的来信:)
它加快了安装速度（例如对于 CI 测试）并提供稳定的依赖状态，所以如果你的 PR 未能通过测试，这是 PR 错误，而不是依赖项之一中的一些不相关的 BC 中断（你仍然需要一些过程来定期更新这个锁）。但这对于环境已知的私有包来说主要是有用的——Symfony 需要支持多个 PHP 版本，所以它们不能真正使用一个锁，所以在 OS 项目中并不流行。
正如 Rob 所说，保持稳定版本是有意义的。当您运行 Composer 安装时，您始终会获得最新版本，并且可能会在您的项目中做出重大更改，或者至少是未经测试的支架。所以其实是一种很常见的方式。