了解Gemfile.lock文件

160

运行bundle install命令后，'Gemfile.lock'在工作目录中创建。该文件中的指令是什么意思？了解Gemfile.lock文件

例如，我们采取以下文件：

PATH 
    remote: . 
    specs: 
    gem_one (0.0.1) 

GEM 
    remote: http://example.org/ 
    specs: 
    gem_two (0.0.2) 
    gem_three (0.0.3) 
     gem_four (0.0.4) 

PLATFORMS 
    platform 

DEPENDENCIES 
    gem_two 
    gem_one!

什么做 'PATH'， '创业板'， 'PLATFORMS' 和 '相关内容' 形容？他们都是必需的吗？

什么应该包含'远程'和'规格'子目录？

'DEPENDECIES'组中的宝石名称后的感叹号是什么意思？

来源

2011-09-22 Shamaoke

你可以找到更多关于它的bundler website（以下重点增加了对您的方便）：

开发了，而你的应用程序后，在应用程序与Gemfile中和Gemfile.lock的一起检查快照。现在，您的存储库记录了您上一次确认应用程序正常工作时使用的所有宝石的确切版本的记录...

这很重要：Gemfile.lock使您的应用程序你自己的代码和它运行的第三方代码的一个包，你最后一次知道所有的工作。指定您在Gemfile中依赖的第三方代码的确切版本不能提供相同的保证，因为gems通常会为其依赖项声明一系列版本。

来源

2011-09-22 16:27:06

+50

这并没有回答他的任何问题，他问的是Gemfile.lock的格式，但这恰恰说明什么确实。 –

关于感叹号，我刚刚发现它在通过:git取得的宝石上，例如，

gem "foo", :git => "[email protected]:company/foo.git"

来源

2012-02-15 01:11:55 agenteo

谢谢。该商标不在任何地方的打包商文档中。 –

哇，好工作搞清楚了，我也想过这个。谢谢。 –

通过'path'选项加载本地gem时也会出现这种情况。我猜测它与加载非编译的gem有关？ – zykadelic

它看起来对我来说，PATH直接列出了从您的gemspec第一代的依赖，而创业板列出了第二代的依赖关系（即你的依赖依赖）和那些从你的Gemfile。 PATH :: remote是.，因为它依赖当前目录中的本地gemspec来查找属于PATH :: spec的内容，而GEM :: remote是rubygems.org，因为这是它必须去查找GEM中属于哪个属性的地方::规格。

在Rails插件中，您将看到PATH部分，但不会显示在Rails应用程序中。由于该应用没有gemspec文件，因此PATH中不会有任何内容。

至于相关性，gembundler.com状态：

Runtime dependencies in your gemspec are treated like base dependencies, 
and development dependencies are added by default to the group, :development

通过rails plugin new my_plugin产生的Gemfile中说类似的话：

# Bundler will treat runtime dependencies like base dependencies, and 
# development dependencies will be added by default to the :development group.

这意味着该

s.add_development_dependency "july" # (1)

之间的差异

s.add_dependency "july" # (2)

是（1）在开发环境中仅包含Gemfile.lock中的“july”（因此在应用程序中）。因此，当您运行bundle install时，不仅会在PATH下看到“七月”，而且还会在依赖项下看到“七月”，但仅在开发阶段。在生产中，它根本就不存在。但是，使用（2）时，只会在PATH中看到“7月”，而不是在相关内容中，但是当您从生产环境中（即在其他包含您作为依赖关系的其他gem中）出现bundle install时，不仅仅是发展。

这些只是我的观察，我不能完全解释为什么这是它的方式，但我欢迎进一步的意见。

来源

2012-09-21 04:00:42

'DEPENDECIES'组中的宝石名称后的感叹号是什么意思？

当使用非“https://rubygems.org”来源安装了宝石时，会出现感叹号。

来源

2016-01-06 10:50:48 SWiggels

Bundler是一个Gem管理器，它通过跟踪和安装所需的精确宝石和版本，为Ruby项目提供一致的环境。

Gemfile和Gemfile.lock是Bundler gem提供的主要产品（Bundler本身就是一颗宝石）。

Gemfile包含您的项目对gem（s）的依赖关系，您可以使用指定的版本手动提及，但这些gem（s）inturn取决于其他由bundler自动解析的gem（s）。

Gemfile.lock包含Gemfile中所有gem（s）的完整快照以及相关的依赖关系。

当您第一次调用bundle install时，它将创建此Gemfile.lock，并在随后的所有调用中使用此文件进行捆绑安装，这可确保安装了所有依赖项并跳过依赖项安装。当您与不同的机器

你的代码中使用的Gemfile一起分享你的Gemfile.lock的，当你运行其它机器会参考您的Gemfile.lock的上捆绑安装，并跳过依赖分辨率

同样的情况，步骤，而是将安装所有你原来的机器上使用相同的依赖宝石（S），其在多台机器

为什么我们需要保持沿米的一致性保持一致性多台机器？

运行在不同的机器不同的版本可能会导致断代码

假设，你的应用程序使用的版本1.5.3，它工作14个月前
没有任何问题，并尝试安装在不同机器上
没有Gemfile.lock现在你得到1.5.8版本。也许它已损坏与最新版本的一些宝石（S）和您的应用程序将
失败。保持一致性至关重要（首选
练习）。

另外，也可以通过使用 bundle update更新Gemfile.lock的宝石（一个或多个）。

这是基于conservative updating

来源

2016-02-21 12:40:51 Keshav

概念似乎没有明确的文件上Gemfile.lock格式说话。也许这是因为Gemfile.lock只是在内部使用。

然而，由于Gemfile.lock是Gemfile快照，（或从默认值如果不是在Gemfile指定），这意味着它的所有的信息应来自Gemfile。

对于GEM，它列出了您在Gemfile中直接或间接引入的所有依赖关系。 remote根据GEM可以知道从何处可以获得宝石，这由在Gemfile中指定。

如果一个宝石不是从remote取得的，PATH会告诉找到它的位置。当您声明依赖关系时，PATH的信息来自path，并在Gemfile中。

和PLATFORM是从here。

对于DEPENDENCIES，它是由bundle解析的依赖关系的快照。

来源

2016-09-09 01:35:11 Hong

我花了几个月的时间搞乱Gemfiles和Gemfile.locks，同时构建了一个自动的依赖关系更新工具。下面的内容远不是明确的，但对于理解Gemfile.lock格式来说，这是一个很好的起点。您可能还想查看Bundler的lockfile parser的源代码。

你会通过捆扎机1.x中生成的锁文件找到以下标题：

GEM（可选的，但很常见）

这些都是从RubyGems的服务器采购的依赖。这可能是Rubygems.org上的主要Rubygems索引，也可能是自定义索引，例如可从Gemfury等公司获得的索引。在本节中，您将看到：

remote:一行或多行指定的RubyGems指数（ES）
specs:依赖列表，用自己的版本号的位置，并在任何subdependencies

GIT（可选）

这些是从给定远程GIT中源的依赖关系。你会看到这些章节对每个远程Git的不同的一个，并且每一节中，你会看到：

remote: git的遥控器。例如，[email protected]:rails/rails
revision:提交参考Gemfile.lock的被锁定到
tag:（可选）中的Gemfile
specs: git的在此远程发现，随着它的版本号指定依赖标记和约束上的任何subdependencies

PATH（可选）

这些是从一给定源依赖在Gemfile中提供了。你会看到这些章节的每个路径依赖的不同的一个，并且每一节中，你会看到：

remote:的路径。例如，plugins/vendored-dependency
specs: git的依赖发现在这个偏远的，与它的版本号，并限制对任何subdependencies

PLATFORMS

的Gemfile.lock的反对产生的Ruby平台。如果Gemfile中的任何依赖关系指定了一个平台，那么当该平台上生成锁文件时（例如，通过安装），它们将仅包含在Gemfile.lock中。

相关内容

这是在Gemfile指定，指定有版本约束沿着依赖关系的清单。具有比主RubyGems的索引之外的源指定

依赖性（例如，GIT中的依赖关系，基于路径的，依赖关系）具有!这意味着它们“固定”到源（尽管有时必须看在在确定的Gemfile中）。

RUBY VERSION（可选）

红宝石在Gemfile中，当创建此Gemfile.lock的指定版本。如果在.ruby_version文件中指定了Ruby版本，则此部分将不存在（因为Bundler将认为Gemfile/Gemfile.lock与安装程序的Ruby版本无关）。

WITH捆绑销售（捆扎机> = v1.10.x）

捆扎机的用于创建Gemfile.lock的版本。用于提醒安装程序更新其Bundler版本，如果它早于创建该文件的版本。

插件的源（可选，非常罕见）

从理论上讲，一个Gemfile中可以指定捆扎机的插件，以及宝石，这将被列在这里。实际上，截至2017年7月，我并不知道有任何可用的插件。Bundler的这部分仍在积极开发中！

来源

2017-07-07 23:05:43 greysteil

似乎是最好的答案 – daslicious

了解Gemfile.lock文件

回答

相关问题