运行rake命令有和没有bundle exec之间的区别

Question

运行rake命令有和没有bundle exec之间的主要区别是什么？

我见过很少的帖子说过，当你使用bundle exec运行命令时，它将在gem文件中定义的gems版本的作用域上运行。如果是这样的话，那么它应该强制运行带有'bundle exec'的rake命令？

Answer 1

bundle exec rake some:task在捆绑包的上下文中运行rake任务。

你没有明确提到Rails的，但我看到你后进行标记使用Rails所以这个动作一做作例子可能是以下几点：

你有虚构whateva-whateva宝石的2.0版本出于某种有效的原因安装在您的系统上。

您决定从某个地方下拉一个旧的Rails项目，并在克隆项目的根文件夹中运行bundle install。该命令将安装Rails应用程序需要的所有宝石，其中一个恰好是虚构的whateva-whateva宝石的版本1.0。

所以目前的状态是这样的：您的旧rails应用程序有一个gem包，其中包含旧版本的whateva-whateva，而您的系统级宝石包含更新版本的whateva-whateva gem。

当您运行与您的Rails应用程序相关的rake任务时，您想要加载哪个版本？当然是老一套。

为了做到这一点，您可以使用bundle exec rake the:task，它会在您的包的上下文中运行rake命令 - 旧版本的gem加上其他任何东西在旧rails应用程序的Gemfile中指定的内容。

所以，毕竟，我认为可以肯定地说最好的做法是，你应该总是预先支付bundle exec，但说实话我很懒，很少这样做，除非我看到问题。

在其他消息中，如果使用Bundler的binstub，则不需要添加它。这里有一个链接设置，最多：http://robots.thoughtbot.com/post/15346721484/use-bundlers-binstubs

Answer 2

BUNDLE_GEMFILE=/path/to/gemfile bundle exec可以用来先于任何命令（如果BUNDLE_GEMFILE未指定它搜索了文件系统，并使用它找到的第一个），而不仅仅是rake。

您运行的任何命令都可能会调用可执行的Ruby命令（例如rake）或需要Ruby库（例如Rake::Task类）的代码，这些东西通常由gems提供。 gem env告诉你gem提供的库和可执行文件在哪里。但是，如果您使用bundle exec，则会将可用宝石限制为与Gemfile关联的Gemfile.lock文件中指定的宝石，您的bundle exec上下文正在使用该宝石。

计算机上使用所有可用的宝石（如果你不这样做bundle exec它可以发生），可以为一对夫妇的原因是不可取的：

• 你可能在你的全宝石集不兼容。
• 很难准确地分辨出你正在使用的是什么宝石，给你的工作环境增加了一些不可预测性。

这里有一个快速的方法来看到其中的差别。一个空的Gemfile，并与内容的文件foo.rb：

1. gem install thin
2. 有两个文件创建一个目录foo
#! /usr/bin/ruby (or whatever the path to your system Ruby is)
require 'thin'
3. 让foo.rb可执行文件。
4. 需要注意的是运行在命令行中都工作thin和./foo.rb，但无论是之前与bundle exec将无法​​正常工作。

Answer 3

如果您在轨的任何命令之前使用bundle exec，它将搜索这是在我们的Gemfile应用的主文件夹中提到的宝石。

假设你有2个应用程序，并使用不同的Ruby版本为他们每个人。 没有bundle exec命令可能无法运行，因为它可能需要不同版本的Gem才能运行该任务。但是，如果你开始使用bundle exec它将采用确切的宝石版本来运行任务/应用程序。

I recommend you to use **bundle exec** before any command.

Answer 4

束-EXEC - 在管束

此命令的上下文中执行的命令执行该命令，使得在Gemfile中（5）可指定为需要Ruby程序所有宝石。

这不是唯一的耙，而不是适用于轨道，RSpec的，rackup命令了。从本质上讲，如果你通常会运行类似rspec spec/my_spec.rb的东西，并且你想要使用Gemfile（5）中指定的并且通过bundle install（1）安装的gems，那么你应该运行bundle exec rspec规格/ my_spec.rb。

注意捆绑高管并不需要一个可执行文件可以用shell的$ PATH。

更多细节，看看到bundle exec文档。