我正在编写一个具有多个 gem 依赖项的 gem，其中一个依赖于一个在较新版本中破坏向后兼容性的 gem。这让我开始思考——我不希望我正在构建的 gem 成为让人们难以更新他们的应用程序的“那个 gem”。我也不想强迫使用我的 gem 的人必须在他们的应用程序的其余部分中使用它所依赖的 gem 的特定版本。
一方面，我可以重写这些依赖项中的所有代码，将它们与我的 gem 捆绑在一起，然后一起删除依赖项，但这似乎有点乏味。有什么方法可以让我简单地将 gem 依赖项直接包含在我的 gem 中，然后将它们包装在一个模块中，这样我的打包版本就不会与应用程序其余部分使用的版本冲突？
【问题讨论】：
标签： ruby-on-rails ruby rubygems bundler gemspecs
我认为通过现有的 Ruby 工具无法实现您想要的。但是，如果您在依赖依赖项时的向后兼容性纯粹是语法/使用问题，而不是版本之间的低级差异，那么您不必导入和维护旧 gem 的代码。您还有另一种选择：在您的 gem 中创建一个“shim”层，从依赖项的新接口或旧接口提供您需要的功能。
实际上它可能看起来像这样，例如假设它是 Thingy 类的构造函数发生了变化：
module DependencyShim
def new_Thingy( new_style_args )
if thingy_is_new
Thingy.new( new_style_args )
else
Thingy.new( convert_args_to_old_style( new_style_args ) )
end
end
# convert_args_to_old_style() not shown
private
def thingy_is_old
Thingy::VERSION < '1.3.4'
end
def thingy_is_new
Thingy::VERSION >= '1.3.4'
end
end
更好的抽象很可能是可能的，但很难预测，因为我不知道新旧差异的本质，以及你的代码与你的依赖关系的紧密程度。
如果版本之间有根本性的变化，这显然会很痛苦，并且您自己的 gem 大量使用依赖项。但即便如此，它仍然可能比在自己的 gem 中重新实现和维护依赖项更痛苦。
我建议让您的 gem 与您的最新版本的依赖项最兼容，并根据您对用户的了解，从长远来看，弃用对旧依赖项的支持根据。可能有充分的理由让所有相关人员摆脱旧的依赖关系。
【讨论】：
假设您使用的是 bundler，您可以像这样在 Gemfile 中指定依赖项的版本：
gem "my_dependency", "0.6.1"
还有很多其他选项，例如“大于 X 的版本”等。阅读bundler docs 了解更多信息。
【讨论】：
1.0.1 与其发布的 gem 不兼容时该怎么办。理想情况下，解决问题的方式意味着最终用户仍然可以在 用户的 项目中使用版本 1.0.1 以及不需要版本 1.0.1 的 gem。 AFAIK，这是不可能的，或者很难实现。