Rails 3 的“bundle install”和“bundle install --deployment”都运行良好，除了第二个只是使用更多的磁盘空间？答案

【问题标题】：Rails 3's "bundle install" and "bundle install --deployment" both work well except the 2nd one just uses more disk space?Rails 3 的“bundle install”和“bundle install --deployment”都运行良好，除了第二个只是使用更多的磁盘空间？
【发布时间】：2010-09-09 23:34:17
【问题描述】：

似乎在开发机器上（比如在 Macbook 上），如果我们使用 bundle install --deployment，所有的 gem 都将安装到 vendor/bundle 文件夹中，如果我们有多个 Rails 3 项目，它只会使用更多的磁盘空间（一些仅用于测试 Rails 3) 的项目。如果不是--deployment，那么gem 将位于“generic”文件夹而不是项目文件夹中，因此可以跨项目共享。这是真的吗？

另外一件事是，我们是否需要将vendor/bundle 下的所有文件添加到我们的存储库并推送？似乎如果我们这样做，我们只是堵塞了 repo，因为如果我们不这样做，所有适当的 gem 将由bundle install 使用Gemfile.lock 中指定的所有 gem 安装。（Gemfile.lock 是 repo 中的一个小文件）。这也是真的吗？

【问题讨论】：

那么bundle install --deployment 是否等同于bundle install --path vendor/bundle？

标签： ruby-on-rails ruby-on-rails-3 bundler

【解决方案1】：

是的！是的。

当您使用--deployment 标志时，Bundler 会确保您需要的每个 gem 都是供应的，即它们被复制到应用程序文件夹结构的预定位置（恰好是 vendor/bundle in按照惯例，Rails）这对两件事有好处。

首先，如果您的权限有限，无法在部署机器中安装 gem，然后让您拥有应用程序中所需的所有 gem。

其次，如果您想破解 gems 中的实际代码，您可以在您出售的副本上执行此操作，而不会影响系统 gems。您所做的更改只会影响您正在处理的应用程序。

这种供应商方法曾经有另一种用途，即确保您使用的是特定版本的 gem，并且即使系统 gem 升级到会破坏您的应用程序的更高版本，您的应用程序也能继续工作。然而，Bundler 本身使这个用例大部分过时了，因为它自动安装和引用特定版本的 gem。

是的，供应商会使您的应用程序代码膨胀。 Gemfile.lock 只是所需宝石的列表。如果您出售您的宝石，它们会被竭尽全力复制到您的应用中。

所以，我建议您不要出售您的宝石（这也意味着不要使用 --deployment 标志），除非您有上述原因之一。

【讨论】：

那么文件夹 vendor/bundle 是否应该添加到 repo 中？有人说，如果那里的文件包含二进制文件，那么如果 Peter 使用 Mac，Tom 使用 Linux，（或者如果部署机器是 Linux），它将破坏系统。我们应该使用bundle package，然后使用bundle install --local，我们应该将它们添加到repo吗？
通常没有。不要出售您的 gem（除非您想更改它们或者您的部署机器不允许您在其中运行 bundle install），更不用说添加到 repo 中了。如你所说，如果每个人都使用不同的系统，那就太浪费空间了。
我希望看到另一个关于使用“捆绑包”的清晰、清晰和简洁的答案。什么时候应该使用“捆绑包”？

【解决方案2】：

我认为，只要 repo 允许您忽略文件，供应商/捆绑包就不会影响 repo。
可以忽略它（如果您使用 git，则添加到 .gitignore 的路径）并且在服务器上有一个符号链接来共享具有多个修订的 gem。

【讨论】：