问我能用'gem install‘或从我的gemfile编辑安装的gem吗？

EN

你能?

是

你应该这样吗？

绝对不是。

为什么？

• 修改gem源代码使升级到较新版本的gem
• 变得非常困难更难调试问题
• 它将导致大量令人头疼的问题
• 它使在协作环境中工作变得困难(是否每个开发人员都有正确的gem？)
• 它会导致这样的问题(即我应该在哪里破解gem?)

解决方案

有几种方法可以解决这个问题：

提交补丁

如果你觉得这个“改变”将使整个社区受益，找到源代码(最有可能在github上)，分支，应用补丁，编写测试，并提交一个拉取请求。如果开发人员同意你的补丁是可行的，它将被合并到项目中，并与下一个版本的gem一起发布。

优势

• 您正在帮助community
• You在您的开发计算机上创建gem的本地副本(因为您已将其派生)

Disadvantages

• 你必须等待开发人员接受你的补丁这可能很time-consuming

重塑宝石

如果您认为这不会使整个社区受益，但您仍然希望允许其他开发人员以系统的方式使用gem，派生现有gem，应用您的补丁，重命名gem并发布。在这种情况下，最好使用原始gem名称作为自定义gem的前缀。例如，如果gem的名称为foo，则应将gem命名为foo-my-company。现在，您可以选择开源gem (推送到rubygems)或将其推送到组织内的私有开发gem服务器。你仍然必须在你的re- gem中找到原始gem作者！

优势

• 无需等待developer
• Central代码库
• Easily

Disadvantages

难以从原始gem进行更新的

• 维护

可能很麻烦

本地库(猴子补丁)

您可以在您的应用程序中创建一个猴子补丁，并覆盖任何不适合您当前环境的方法或属性。

优势

• 快速易用的
• 轻松共享(通过git -只需将修补程序文件包含在您的资源库中)

Disadvantages

difficult

• It's
• 更新gem对于其他开发人员来说，您正在修改gem的核心
• 难以调试(是gem还是您的修补程序出错？)

Fork和Source

这是我推荐的选项。为什么我把它放在最后--其他的更常见。在这种方法中，您从原始存储库(可能在github上)派生gem，然后从git存储库获取gem。例如，假设gem名为foo，您可以在github上将foo派生为username/foo。应用你的补丁，改变，任何东西。然后在你的Gemfile中：

gem 'gem_name', :git => 'git://github.com/username/foo'

这将在每次运行命令时从代码库的源代码安装和编译gem。您还可以指定特定的标签和分支(建议用于稳定性)。

优势

对于上游的分支，您可以轻松地进行更新(您可以从上游进行分叉，合并，您可以轻松地对所有changes)

• Version进行控制(使用标签和分支可以访问相同的gem源

• 易于管理的更新

Disadvantages

• 您的“自定义”代码是公开的(尽管您可以使用自定义git服务器而不是github来解决这个问题)

结论

每种方法都有自己的优点和缺点(我已经尽可能地列举出来)。在任何情况下，您建议的方法是，而不是解决该问题的推荐方法。

如果读者对其他优点/缺点有意见，请列出它们，我会将它们添加到我的答案中。

当然，这只是代码。

你应该这样吗？通常不会，因为它可以重新安装、更新等。

因为你可以重新打开类，所以更安全的方式是修补、拥抱和扩展等等。当然，这并不总是像直接修改一样实用。

出于教育目的(如果修改丢失并不重要)，它很好，而且比重复所有内容更有意义。不过，AOP-ish日志记录通常在不修改原始源的情况下是可行的。有时克隆存储库并使用它，特别是在探索阶段，会更干净。

戴夫·牛顿的建议是明智的，你应该采纳它，但看看它来学点什么也没什么错。运行gem env将向您显示gem的安装位置；您可以在lib目录中找到代码的主要部分。