Jon*_*ard 11 ruby gem bundler pry
我正在尝试调试Rails应用程序使用的gem.
我在当地克隆了Gem以进行撬动(并且还允许我做诸如此类的好东西git bisect)
# Gemfile
gem "active_admin", path: "~/dev-forks/active_admin"
但是,我经常坚持将Pry添加到Gemfile某处以便能够使用它,或者require "pry"在代码中调用live,即使我不想在那里使用它.例如,我有时会忘记它,修复bug,然后在Gemfile中使用Pry提交项目.
如果我不这样做,LoadError就会出现cannot load such file -- pry (LoadError).
我必须管理我在不同的上下文(Rails项目,Gem,本地Ruby)和实际的Gems(Gemfile,require,installed)之间有点迷失.
如何binding.pry在没有Gemfiles干预的情况下在Rails中使用Gem？
过去的乔恩!如你所知,我有(几乎)所有问题的答案.
在这种情况下,你实际上是在描述两个问题:(a)require 'pry'当Pry不在Gemfile中时你不能,(b)你不能使用Pry require.
正如康拉德欧文所写的那样,Bundler所做的是:
Bundler是一个令人敬畏的宝石,它给你一个很好的信心,"如果它在开发中工作,它在生产中工作".它可以通过对gem依赖关系恶毒来做到这一点:如果它不在Gemfile中,那就不需要了.它还确保每个人的开发环境都是相同的,"它在我的机器上工作"不再是一个借口.
在某种情况下,这种教条式的奉献精神可能会妨碍他们.特别是所有优秀的开发人员都非常个人地建立了他们的开发环境 显然,我的本地工具在生产中工作并不重要,如果每个人都被迫拥有一个正确的开发设置,那么这对生产力来说是非常不利的.
因此,在完成Bundler为Ruby开发人员所做的所有好事之前,设计需要注意:"捆绑/ Gemfile之外的东西(例如系统宝石)不再存在." 它是如何做到这一点的,通过重新定义require过程并更改您的过程,PATH以便它只看到捆绑中的内容.
这意味着你不能在不污染Gemfile的情况下使用Pry,你说,对吧？没那么快.康拉德欧文是他聪明的小饼干,想出了一个解决方案并制作了Pry Debundle,这个宝石可以暂时扭转Bundler对我们要求的补丁.
所以你要做的就是require 'pry-debundle'那时,对吗？等一下.是的,Debundle可能不在Gemfile中.
猴子的解决办法是硬拷贝的来源pry-debundle.rb来~/debundle.rb,然后load这一点.(现在,你需要Pry加载来运行那个源文件,但是你只能运行debundle!方法到达那里,需要Pry,然后去撬动.需要一点点monkeypatching,但我正在研究PR. )
如果你想在你的rails应用程序中使用和调试gem，那么它应该位于你应用程序中Gemfile的开发和测试组中。
您可以使用 pry-debugger https://github.com/nixme/pry-debugger等工具在 pry 会话中设置断点break SomeClass#run。
我认为向我分叉的每个项目添加 pry 来修复错误或贡献内容是有效的。只是不要将其放入.gemspec文件中。
如果您要将binding.pry更改推送到存储库，则应该像吉姆指出的那样添加提交挂钩。我不认为这是一个与撬动相关的问题，这取决于您在推出差异之前检查差异时的小心程度。