blocks|key|1803055|text|至于感叹号，我刚刚发现它在通过:git获取的宝石上，例如|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1803056|gem+"foo",+:git+=>+"git@github.com:company/foo.git"|code-block|syntax|javascript|1803057|entityMap^0|F|4|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

in regards to the exclamation mark I just found out it's on gems fetched via <code>:git</code>, e.g.

<pre><code>gem "foo", :git =&gt; "git@github.com:company/foo.git"
</code></pre>

blocks|key|1588681|text|在我看来，PATH直接列出了gemspec中的第一代依赖项，而GEM则列出了第二代依赖项(即您的依赖项所依赖的内容)和Gemfile中的依赖项。remote是.，因为它依赖于当前目录中的本地gemspec来查找属于PATH::spec中的内容，而GEM::remote是rubygems.org，因为要查找属于GEM::spec中的内容就必须转到GEM：：spec中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1588682|在Rails插件中，您将看到路径部分，但在Rails应用程序中却看不到。由于应用程序没有gemspec文件，因此在PATH中将没有任何内容可放入。|1588683|对于依赖关系，gembundler.com声明：|1588684|Runtime+dependencies+in+your+gemspec+are+treated+like+base+dependencies,+
and+development+dependencies+are+added+by+default+to+the+group,+:development|code-block|syntax|javascript|1588685|由rails+plugin+new+my_plugin生成的Gemfile表示类似的内容：|1588686|#+Bundler+will+treat+runtime+dependencies+like+base+dependencies,+and
#+development+dependencies+will+be+added+by+default+to+the+:development+group.|1588687|这意味着两者之间的差异|1588688|s.add_development_dependency+"july"+#+(1)|1588689|和|1588690|s.add_dependency+"july"+#+(2)|1588691|(1)在开发环境中，(1)将只在Gemfile.lock+(因此也包括在应用程序中)中包含“七月”。因此，当您运行bundle+install时，您不仅会在PATH下看到“七月”，还会在依赖项下看到“7月”，而且只在开发中。在生产中，它根本不会在那里。然而，当你使用(2)时，你只会在路径中看到“七月”，而不会在依赖中看到，但是当你从一个生产环境(也就是在其他一些包含你的依赖的gem中)+bundle+install时，它会显示出来，而不仅仅是在开发中。|1588692|这些只是我的观察，我不能完全解释为什么它是这样的，但我欢迎进一步的评论。|1588693|entityMap|0|LINK|mutability|MUTABLE|url|http://gembundler.com/v1.2/rubygems.html^0|27|1|3R|C|0|0|7|E|0|0|0|1|Q|0|0|0|0|0|0|1L|E|5F|E|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1H|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1I|8|@]|D|@$9|1J|A|1K|1|1L]]|E|$]]|$1|J|3|K|5|L|7|1M|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|1N|8|@$9|1O|A|1P|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|L|7|1Q|8|@]|D|@]|E|$M|N]]|$1|S|3|T|5|6|7|1R|8|@]|D|@]|E|$]]|$1|U|3|V|5|L|7|1S|8|@]|D|@]|E|$M|N]]|$1|W|3|X|5|6|7|1T|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|L|7|1U|8|@]|D|@]|E|$M|N]]|$1|10|3|11|5|6|7|1V|8|@$9|1W|A|1X|B|C]|$9|1Y|A|1Z|B|C]]|D|@]|E|$]]|$1|12|3|13|5|6|7|20|8|@]|D|@]|E|$]]|$1|14|3|-4|5|6|7|21|8|@]|D|@]|E|$]]]|15|$16|$5|17|18|19|E|$1A|1B]]]]

It looks to me like PATH lists the first-generation dependencies directly from your gemspec, whereas GEM lists second-generation dependencies (i.e. what your dependencies depend on) and those from your Gemfile. PATH::remote is <code>.</code> because it relied on a local gemspec in the current directory to find out what belongs in PATH::spec, whereas GEM::remote is <code>rubygems.org</code>, since that's where it had to go to find out what belongs in GEM::spec.

In a Rails plugin, you'll see a PATH section, but not in a Rails app. Since the app doesn't have a gemspec file, there would be nothing to put in PATH.

As for DEPENDENCIES, <a href="http://gembundler.com/v1.2/rubygems.html" rel="noreferrer">gembundler.com</a> states:

<pre><code>Runtime dependencies in your gemspec are treated like base dependencies, 
and development dependencies are added by default to the group, :development
</code></pre>

The Gemfile generated by <code>rails plugin new my_plugin</code> says something similar:

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

What this means is that the difference between

<pre><code>s.add_development_dependency "july" # (1)
</code></pre>

and

<pre><code>s.add_dependency "july" # (2)
</code></pre>

is that (1) will only include "july" in Gemfile.lock (and therefore in the application) in a development environment. So when you run <code>bundle install</code>, you'll see "july" not only under PATH but also under DEPENDENCIES, but only in development. In production, it won't be there at all. However, when you use (2), you'll see "july" only in PATH, not in DEPENDENCIES, but it will show up when you <code>bundle install</code> from a production environment (i.e. in some other gem that includes yours as a dependency), not only development.

These are just my observations and I can't fully explain why any of this is the way it is but I welcome further comments.

blocks|key|1588799|text|似乎没有关于Gemfile.lock格式的明确文档。也许是因为Gemfile.lock只是由捆绑包在内部使用。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1588800|但是，由于Gemfile.lock是Gemfile的快照，这意味着它的所有信息都应该来自Gemfile+(如果没有在Gemfile中指定，则来自默认值)。|1588801|对于GEM，它列出了您在Gemfile中直接或间接引入的所有依赖项。GEM下的remote告诉从哪里获取get，这是由source在Gemfile中指定的。|1588802|如果没有从remote中获取宝石，PATH会告诉该位置如何找到它。当你声明一个依赖项时，PATH的信息来自Gemfile中的path。|1588803|而PLATFORM来自here。|1588804|对于DEPENDENCIES，它是包解析的依赖项的快照。|1588805|entityMap|0|LINK|mutability|MUTABLE|url|http://bundler.io/man/gemfile.5.html#GLOBAL-SOURCES|1|http://bundler.io/man/gemfile.5.html#PATH|2|http://bundler.io/man/gemfile.5.html#PLATFORMS^0|6|C|V|C|0|5|C|I|7|18|7|1M|7|0|2|3|C|7|Y|3|13|6|1U|7|1N|6|0|0|5|6|H|4|18|4|1H|7|1Q|4|1|0|1|8|B|4|2|0|2|C|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|16|8|@$9|17|A|18|B|C]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1F|8|@$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]|$9|1O|A|1P|B|C]]|D|@$9|1Q|A|1R|1|1S]]|E|$]]|$1|J|3|K|5|6|7|1T|8|@$9|1U|A|1V|B|C]|$9|1W|A|1X|B|C]|$9|1Y|A|1Z|B|C]|$9|20|A|21|B|C]]|D|@$9|22|A|23|1|24]]|E|$]]|$1|L|3|M|5|6|7|25|8|@$9|26|A|27|B|C]]|D|@$9|28|A|29|1|2A]]|E|$]]|$1|N|3|O|5|6|7|2B|8|@$9|2C|A|2D|B|C]]|D|@]|E|$]]|$1|P|3|-4|5|6|7|2E|8|@]|D|@]|E|$]]]|Q|$R|$5|S|T|U|E|$V|W]]|X|$5|S|T|U|E|$V|Y]]|Z|$5|S|T|U|E|$V|10]]]]

It seems no clear document talking on the <code>Gemfile.lock</code> format. Maybe it's because <code>Gemfile.lock</code> is just used by bundle internally.

However, since <code>Gemfile.lock</code> is a snapshot of <code>Gemfile</code>, which means all its information should come from <code>Gemfile</code> (or from default value if not specified in <code>Gemfile</code>).

For <code>GEM</code>, it lists all the dependencies you introduce directly or indirectly in the <code>Gemfile</code>. <code>remote</code> under <code>GEM</code> tells where to get the gems, which is specified by <a href="http://bundler.io/man/gemfile.5.html#GLOBAL-SOURCES" rel="nofollow noreferrer">source</a> in <code>Gemfile</code>.

If a gem is not fetch from <code>remote</code>, <code>PATH</code> tells the location to find it. <code>PATH</code>'s info comes from <a href="http://bundler.io/man/gemfile.5.html#PATH" rel="nofollow noreferrer">path</a> in <code>Gemfile</code> when you declare a dependency. 

And <code>PLATFORM</code> is from <a href="http://bundler.io/man/gemfile.5.html#PLATFORMS" rel="nofollow noreferrer">here</a>.

For <code>DEPENDENCIES</code>, it's the snapshot of dependencies resolved by bundle.

After running the <code>bundle install</code> command, 'Gemfile.lock' is created in the working directory. What do the directives inside that file mean?

For example, let's take the following file:

<pre><code>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!
</code></pre>

What do 'PATH', 'GEM', 'PLATFORMS' and 'DEPENDENCIES' describe? Are all of them required?

What should contain the 'remote' and 'specs' subdirectives?

What does the exclamation mark after the gem name in the 'DEPENDENCIES' group mean?

Understanding the Gemfile.lock file

运行bundle install命令后，将在工作目录中创建'Gemfile.lock‘。该文件中的指令是什么意思？例如，让我们以下面的文件为例：PATH  remote: .  specs:    gem_one (0.0.1)GEM  remote: http://example.org/  specs:    ge...

问了解Gemfile.lock文件
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问了解Gemfile.lock文件EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问了解Gemfile.lock文件
EN