我正在尝试调试Rails应用程序使用的gem。
我在当地克隆了Gem以进行窥探（并且还允许我做诸如git bisect之类的好事。）
# Gemfile
gem "active_admin", path: "~/dev-forks/active_admin"
但是，我经常坚持将Pry添加到Gemfile某处以便能够使用它，或者在代码中调用require "pry"，即使我不想在那里使用它。例如，我有时会忘记它，修复bug，然后在Gemfile中使用Pry提交项目。
我不应该这样做，LoadError会出现cannot load such file -- pry (LoadError)。
我必须管理我在不同的上下文（Rails项目，Gem，本地Ruby）和实际的gems（Gemfile，require，installed）之间有点迷失。
如何在没有Gemfiles干预的情况下在Rails中的Gem中使用binding.pry？
答案 0 :(得分：7)
乔恩过去！如你所知，我（几乎）解决了你所有的问题。
在这种情况下，您实际上描述了两个问题：（a）当Pry不在Gemfile中时你不能require 'pry'，（b）你不能使用Pry如果你不require它。
Bundler的作用，如Conrad Irwin writes：
Bundler是一个非常棒的宝石，它给你很大的信心，如果它在开发中有效，它可以在生产中使用＆＃34;。它可以通过对gem依赖关系恶毒来做到这一点：如果它不在Gemfile中，它就不会被要求。它还确保每个人的开发环境都是相同的，没有更多的开发环境可以在我的机器上运行＆＃34;把它当作借口。
在某种情况下，这种教条式的奉献精神会妨碍他们。特别是所有优秀的开发人员都非常个人地建立了他们的开发环境显然，我的本地工具在生产中工作并不重要，如果每个人都被迫拥有一个识别性的开发设置，它对生产力的积极影响。
所以在完成Bundler为Ruby开发人员所做的所有好事时，它的设计需要注意：＆＃34; bundle / Gemfile之外的内容（例如系统gems）不会＆＃39 ; t已存在。＆＃34;如何做到这一点，重新定义require进程并更改PATH，以便它只能看到捆绑包中的内容。
这意味着你可以根本不使用Pry而不污染Gemfile，你说，对吧？没那么快。 Conrad Irwin是他聪明的小饼干，提出了一个解决方案并制作了Pry Debundle，这是一个暂时扭转Bundler根据我们要求制作的补丁的宝石。
所以你要做的只是require 'pry-debundle'，对吧？等一下。是的，Debundle可能不在Gemfile中。
猴子修复是将pry-debundle.rb的来源硬拷贝到~/debundle.rb，然后load。 （现在，你需要加载Pry才能运行该源文件，但是你只能运行debundle!方法来实现，需要Pry，然后去撬动。需要一点点monkeypatching，但我和＃39;正在研究PR。）
答案 1 :(得分：1)
如果你想在rails应用程序中使用和调试gem，那么它应该在你应用程序中Gemfile的开发和测试组中。
您可以使用pry-debugger https://github.com/nixme/pry-debugger等工具在您的pry会话break SomeClass#run中设置断点。
我认为将pry添加到我为解决错误或贡献内容而分叉的每个项目都是有效的。只是不要把它放在.gemspec文件中。
如果你要对你的仓库进行binding.pry更改，你应该像Jim指出的那样添加提交钩子。我不认为这是一个与撬相关的问题，它取决于你在推出它之前审查你的差异时需要多少照顾。