在一个Ruby项目中，我有一个依赖项，它被我的gem使用，同时也被我的gem依赖的另一个gem使用。具体来说，我使用sawyer和octokit，所以my-gem依赖于sawyer,octokit也依赖于sawyer。
现在，我有:
spec.add_runtime_dependency 'octokit', '~> 6.0'
spec.add_runtime_dependency 'sawyer' # no version constraint
这工作很好，现在，但我想知道这是否是最好的方式来做事情。目的是使用octokit使用的任何版本的sawyer，但我想知道是否有一个版本约束更好，或者只是从gemspec中省略sawyer。
TL;DR
Gems通常是库，而不是应用程序，尽管也有例外。库应该只在它们的gem规范中列出那些第一类依赖的gem，并避免在gem上构建不必要的或过于严格的约束。
列出什么和约束多少
何时列出和约束宝石
根据经验，gem(与应用程序相反)不应该约束gem的依赖关系，除非有必要避免特定的冲突。否则，您可能会不必要地限制其他人对您的gem的使用，这些人有其他限制，或者出于任何原因需要更新或更早的版本。
所以，假设你的gem确实需要octokit>= 6.0和<= 6.1，那么就那样约束它吧。否则，在最大程度上降低或减少约束的水平。例如，如果一个依赖项遵循语义版本控制，那么您应该只约束它的主要版本(如果您要约束它的话)，除非您需要避免的特定次要版本或补丁版本存在已知问题。换句话说，要尽可能自由地使用标准库约束。
不要重复绑定器或上游库的职责
如果你没有直接调用sawyer gem，那么它实际上只是一个与你的gem无关的octokit的依赖。在这种情况下，您应该信任Bundler对octokit的依赖解析，除非您发现一个特定的问题，否则它会拉入所需的功能。否则，您将最终管理可能在上游更改的依赖关系，这将为库的维护和使用它的任何开发人员创建不必要的负担。
另一方面，如果你的gem直接调用sawyer，那么它应该是你的gemspec中列出的第一个类依赖。同样，如果需要的话，保持约束尽可能宽松，以避免过多的约束或不得不不断更新次要或补丁版本。
简而言之，如果列出sawyer的唯一原因是因为octokit当前使用它，那么Bundler应该管理该依赖项。理想情况下，octokit维护者应该在需要时更新octokit的依赖项。只有在绝对必要的时候才管理第三方依赖，并且只有在必要的修复被合并到上游库(或者如果你需要的修复不会被合并到一个合适的分支或库替换中)时才管理。