0

我在一个工程师团队中工作，该团队使用本机可执行文件开发 gem。出于合同原因，重要的是，当我们部署到新环境时，所有依赖项都使用与我们测试过的完全相同的版本。Gemfile只能维护一阶依赖版本，不能维护递归版本。出于这个原因，我们一直将锁定文件签入 github，但这阻止了我们自 1.14 版本以来升级捆绑器。问题是我们有 OSX 和 Linux 的开发机器，从 1.14 开始，gem 存储库中的 lockfile 的开头更改为：

PATH
  remote: .
  specs:
    engine (21.2.13)
      <gemspec dependencies here>

至

PATH
  remote: .
  specs:
    engine (21.2.13-x86_64-linux)
      <gemspec dependencies here>

这是一个问题，因为当开发人员在 OSX 上提取 repo 并运行bundle install时，它会更改锁定文件的内容。然后，当一个 linux 开发人员做同样的事情时，它会再次发生变化，在 lockfile 的 git 历史记录中创建一堆虚假的变化！

我尝试运行bundle lock --add-platform x86_64-linuxand bundle lock --add-platform x86_64-darwin，希望这能说服 bundler 为不同平台维护两个条目，而不是在它们之间翻转。它确实为 lockfile 部分中的某些 gem 生成了重复条目GEM，但没有为该部分中的 gem 生成重复条目PATH\n specs:。

目前，我们的 Gemfile 包含以下行：

gemspec name: "engine"

加载engine.gemspec。该文件包含：

Gem::Specification.new do |spec|
  ...
  spec.platform = Gem::Platform::CURRENT
  ...
end

我怀疑这是问题所在。我尝试在 Gemfile中包含两次gemspec，并使用全局变量来指定要使用的平台，但捆绑器仅在第一次加载它，并跳过第二次尝试。

有谁知道允许我们将两个特定于平台的 gem 版本保存在同一个锁文件中的解决方案？

或者，有没有办法关闭捆绑器的新行为，将平台名称附加到 gem 版本？过去，当 lockfile 简单地指定“21.2.13”并且我们的 gemserver 包含每个版本的两个副本（以及为两个平台构建的二进制文件）时，bundler 在解析当前机器的正确版本时从来没有任何问题，所以这似乎就像存储多余信息的锁文件一样。我能以某种方式告诉它停止吗？

4

1 回答 1

0

我听说过各种建议和不建议将您的锁定文件放在版本控制中，但从未完全理解其原因。这似乎是问题的根源！

我最常看到的建议（尽管这可能并不总是可行）是锁定文件永远不应该在 gem 的版本控制之下，而总是在独立的应用程序中。这个想法是 gem 旨在是可移植的，因此它的依赖关系应该具有一定的灵活性。重要的是，这种灵活性不会妨碍我们的开发环境保持一致，前提是所有测试都不是在 gem 存储库中进行，而是在使用 gem 的独立应用程序的存储库中进行。

该独立应用程序的锁定文件已经跟踪了我们认为我们使用 gem 的锁定文件来跟踪的依赖项，并且当应用程序被部署时，所有 gem 的依赖项都固定在应用程序内部，而不是 gem 内部。

的“规范”部分Gemfile.lock应该只存在于 gem 存储库中，并且该部分以平台相关的方式命名 gem 的事实不是问题，因为 gem 是由锁定文件中的平台无关名称引用的使用它的应用程序。

于 2017-09-13T14:01:46.213 回答