Gemfile.lock在部署环境中具有不同版本的Rake
简而言之,错误消息如下所示:
$ bundle install
rake aborted!
You have already activated rake 0.9.2.2, but your Gemfile requires rake 0.9.2. Using bundle exec may solve this.
以下是此错误的解释:
- 部署服务器已安装
rake 0.9.2.2
- 应用程序
Gemfile
没有Gemfile
所需的版本号 < code>rake - 开发者的开发环境安装了
rake
0.9.2,此版本号位于Gemfile.lock
文件中 - 部署服务器安装了许多 Rails 应用
- 程序应用程序是由不同的程序员
- 这些程序员在他们的开发环境中安装了不同的rake版本,
- 其中一些有
rake 0.9.2
,另一些有rake 0.9.2.2
- 通过阅读耶胡达·卡茨的澄清 .gemspec 和 Gemfile 的角色,
Gemfile.lock
文件位于我们的 subversion
可能的解决方案:
- 错误消息可以通过运行
bundle 来避免exec rake install
然后,如果我们要求所有开发人员在Gemfile
中指定相同版本的 rake,则可以避免bundle update
- 消息
- 错误 耙
我的问题是:这是正确的解决方案吗?或者有什么正确的解决方案吗?
我仍然不确定 Gemfile.lock
文件应该在 subversion 中。
In short, the error message looks like following:
$ bundle install
rake aborted!
You have already activated rake 0.9.2.2, but your Gemfile requires rake 0.9.2. Using bundle exec may solve this.
And here is the explanation for this error:
- deployment server has
rake 0.9.2.2
installed - application
Gemfile
has no required version number forrake
- developer's development environment has
rake
0.9.2 installed and this version number is inGemfile.lock
file - deployment server has a number of rails applications installed
- these applications are written by different programmers
- these programmers have different rake version installed in their development environment
- Some of them have
rake 0.9.2
and others haverake 0.9.2.2
- By reading Yehuda Katz's Clarifying the Roles of the .gemspec and Gemfile,
Gemfile.lock
file is in our subversion
Possible Solutions:
- error message could be avoided by running
bundle exec rake install
thenbundle update
- error message could be avoided if we asked all developers to specify same version of rake in
Gemfile
- ask all developers to use same version of rake
My question is: is this the correct solution here? or is there any correct solutions?
I am still not really sure the Gemfile.lock
file should be in subversion.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您绝对应该检查您的 Gemfile.lock。它包含您知道可与您的应用程序配合使用的 gem 版本。因此,当您在不同的环境上捆绑安装时,您知道它应该可以工作。
假设几个月后有人在没有 Gemfile.lock 的情况下进行捆绑安装。他们将在您的 Gemfile 中获取最新版本的 gem(至少是具有指定版本的gems),并且无法保证您的应用程序甚至可以使用这些 gem。使用 Gemfile.lock,应该可以保证您的应用程序应该运行,因为任何使用过它或对其进行测试的人都应该将其与那些冻结的 gem 版本一起处于通过状态。
要解决您的问题,我会这样做:
然后提交 Gemfile 和 Gemfile.lock。这样你就可以告诉任何运行你的应用程序的人你应该使用 0.9.2.2 的 rake。这是您知道将与您的应用程序配合使用的 rake 版本,并且您的测试将针对此版本运行。
要实际运行正确的版本,您有几个选项:
bundle exec:
向 .bash_profile、.zshrc 或 .profile 添加别名也可能有帮助:
bundle binstubs
.bash_profile 中的
这会将 Gemfile 的二进制文件安装到 ./bin 目录,并且路径更改将强制您的 shell 在查看 rvm 或 gem 安装二进制文件之前先签入 ./bin。如果执行此操作,请记住将“bin”添加到您的 .gitignore 文件中。
You should definitely be checking in your Gemfile.lock. It contains the versions of your gem you know will work with your application. So when you bundle install on a different environment you know it should work.
Say a few months from now someone does a bundle install without a Gemfile.lock. They will get the latest version of gems in your Gemfile (at least the ones with a specified version) and there will be no guarantee that your app will even work with those gems. With a Gemfile.lock, there should be some assurance that your app should run, since anyone who's worked with it or ran tests on it should have had it in a passing state with those frozen gem versions.
To resolve your issue, I would do:
and then commit Gemfile and Gemfile.lock. This way you're telling anyone who runs your app that you should be using 0.9.2.2 of rake. This is the version of rake you know will work with your app and your tests are run against this version.
To actually run the correct version you have a few options:
bundle exec:
Adding an alias to your .bash_profile, .zshrc, or .profile might also help:
bundle binstubs
This will install your Gemfile's binaries to ./bin directory and the path change will force your shell to check in ./bin first before looking in rvm or your gem install binaries. Remember to add 'bin' to your .gitignore file if you do this.
如果您的团队试图让每个人都使用同一版本的 rake(第二个和第三个解决方案)并管理所有下游冲突,那么您的团队将经历生产力的消耗,这可能会非常高。当开发人员需要使用 gem/script/module XYZ 但 XYZ 和
rake
的强制版本存在问题时,这也会增加开发人员的挫败感。只要采取措施确保
bundle
命令在您的环境中高效执行,解决方案 1 对团队生产力的负面影响就会小得多。恕我直言。The productivity drain your team will experience with trying to keep everyone on the same version of
rake
(2nd and 3rd solutions) and managing all the downstream conflicts could be very high. It will also raise the level of developer frustration when they need to use gem/script/module XYZ but there is a problem with XYZ and the mandated version ofrake
.As long as take steps to ensure the
bundle
commands execute efficiently in your environment, Solution 1 will make a much smaller negative impact on the productivity of your teams. IMHO.