Same as bundler-inject?

[Fryguy]

Hi all. I noticed this new bundler plugin, and was curious if this offered the same functionality as bundler-inject? Seems similar.

[tarnowsc]

Hi @Fryguy, this work is heavily inspired by bundler-inject, but serves slightly different purpose. We needed a tool that would allow to use a published dependency and allow to override its transient dependencies, allowing to remove them or update the version requirements. Such functionality is available in dependency management tools for other languages but not for ruby. This is mainly needed when your dependency is abandoned and no one maintains its dependencies which may contain CVEs. Also can help when you have a conflicting versions of transient dependencies, like one of your dependency requires gem x in version < 2 and another in version > 2. Another case is when your dependency has broad functionality and you don't need all of that, like Chef and support for windows when targeting linux only. Of course modifications of transient dependencies is unsafe and can break your direct dependencies, so one needs to verify that such changes did not introduced a regression in their functionality. Also if you use that and something breaks that's definitely not a fault of the original gem maintainers. To the best of my understanding of how bundler-inject works such use case would require persisting of a modified version of your dependency with your code.

[Fryguy]

Ah, thanks for the details. Sounds like the use case is similar to npm overrides?

To the best of my understanding of how bundler-inject works such use case would require persisting of a modified version of your dependency with your code.

Only if the override requires code changes would the code need to be available. The override_gem directive in bundler-inject can also just take a version a parameter, so you could point to a different updated version of a transitive dependency.

If the gem does need to be modified, then the modified version would need to be available somewhere and published. It could be vendored alongside your code, but it could also just be a git fork or packaged to a custom rubygems instance. Since rubygems doesn't support namespacing, I don't think you could publish into rubygems.org (I wish there was an option to gem that you could point to a different gem and say "use this gem and pretend it's really the listed gem").

So, I think you could use bundler inject for your purposes, where you would persist a file into the bundler.d directory, but admittedly that does start blurring the lines between dev and prod use cases.

---

Have you opened an issue in rubygems discussing an overrides directive? (or perhaps there's already an open issue - I didn't check) Considering it's in other package managers, there's strong evidence of its utility, and the security aspects you described help give weight to the argument.

[Fryguy]

Oh, I forgot to mention, we do want to support overriding transitive dependencies, but there's just a bug right now (this one). So, if that helps your use case, we'd be happy to accept a PR to fix that. I just haven't been able to figure it out (nor do I have cycles for it at the moment).