使用和不使用bundle exec运行rake命令之间的区别

Question

使用和不使用bundle exec运行rake命令之间的主要区别是什么？

我看到很少有帖子说当你用bundle exec运行命令时它会在gem文件中定义的gems版本的范围内运行。 如果是这种情况，那么应该强制使用bundle exec运行rake命令？

Answer 1

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

你没有明确提到Rails，但我看到你的帖子被标记为Rails，所以这个实际的例子可能如下：

出于某些正当理由，您的系统上安装了虚构的whateva-whateva gem版本2.0。

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

所以当前状态是这样的：你的旧rails应用程序有一个宝石包，其中包括旧版本的whateva-whateva ，你的系统范围的宝石包括更新版本的whateva-whateva宝石。

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

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

所以，是的，我认为最好的做法是你应该总是在bundle exec但老实说，我很懒，很少去做，除非我看到问题。

在其他新闻中，如果你使用Bundler的binstubs，你不需要添加它。 以下是设置该链接的链接： https ： //thoughtbot.com/blog/use-bundlers-binstubs

Answer 2

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

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

使用机器上所有可用的宝石（如果你不执行bundle exec ，可能会发生这种情况）可能是不可取的，原因如下：

• 您的完整宝石套装中可能存在不兼容性。
• 很难准确地说出你正在使用的宝石，为你的工作环境增加了一些不可预测性。

这是一个快速查看差异的方法。

1. gem install thin
2. 使用两个文件创建一个目录foo ：一个空的Gemfile和一个带有内容的文件foo.rb ：
   #! /usr/bin/ruby (or whatever the path to your system Ruby is)
require 'thin'
3. 使foo.rb可执行。
4. 请注意， ./foo.rb运行thin和./foo.rb都可以工作，但是在bundle exec将不起作用。

Answer 3

如果在rails中的任何命令之前使用bundle exec ，它将在应用程序主文件夹中搜索我们的Gemfile中提到的Gems。

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

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

Answer 4

bundle-exec - 在bundle的上下文中执行命令

该命令执行命令，使得Gemfile（5）中指定的所有gem在Ruby程序中都可用。

它不是唯一的rake，而是适用于rails，rspec，rackup命令。

基本上，如果你经常运行像rspec spec / my_spec.rb这样的东西，并且你想使用Gemfile（5）中指定的gems并通过bundle install（1）安装，你应该运行bundle exec rspec spec / my_spec。 RB。

请注意，bundle exec不要求shell的$ PATH上有可执行文件。

有关更多详细信息，请查看捆绑exec文档。