Jean Boussier

> Removing that brings me to the same problems with TruffleRuby. Whenever you figure out how to solve that in your branch Ah, I didn't notice there was an issue...

> Could you add answers to those questions? Many don't seem to really apply here, but let's try: > Why are we doing this? What use cases does it support?...

> the various gems that depend on `left-pad` can progressively decide to update their dependency declaration, but in the meantime users have a way out of the problem, and are...

> The only escape I know of is for the application developer to fork those gems and update them to all use the same dependency. Well, no because `gem as:`...

Also a simpler implementation of this feature could be to just mark a gem being "de-activated", e.g.: ```ruby gem "some-gem-that-depend-on-left-pad" gem "left-pad", disabled: true gem "left-padder" ``` `disabled: true` would:...

> Luckily this gem is not part of gem dependencies and should be easy to fork and migrate projects to. It is, See: https://rubygems.org/gems/unicorn/reverse_dependencies and https://github.com/unicorn-ruby/unicorn/issues/1 > It seems there...

> Would in this case the proposed solution (keep the feature behind some strange ENV and provide warnings or so) works for you for this usecase? It would solve the...

> is your intention to maintain forks (but keeping the name) so everyone can use them using "overriding feature"? Yes, and also to allow others to do the same. Basically...

> What about scoped gems? Would that work for your usecase? IMHO it's exactly the same feature. Whether the namespace is in the gem name itself, or in an additional...

NB: the idea of namespace came up when I first suggested this feature internally, but I didn't propose it because it seemed like a much more radical change to both...