https://github.com/rubygems/rubygems/commit/0c3a65871a

After having a second look at this deprecation, the explanation that
we're giving does not make a lot of sense. When working only with local
gems, Bundler will indeed generate a different lockfile depending on
the latest installed version of each gem is at `bundle install` time.

That's the same situation that happens with remote sources: Bundler will
generate a different lockfile depending on the latest version of each
gem available remotely.

So, I don't think "a consistent lockfile not getting generated" is a
good motivation for deprecating this.

Also, this deprecation brings additional challenges, since for example,
it should arguably not get printed when using `bundle install --local`?

The original problem when this deprecation was introduced was an
incorrect message about a missing gem having been yanked.

So, I think a better solution is to, as long as we give proper error
messages when things go wrong, let users do what's best for them and
undo the deprecation.

https://github.com/rubygems/rubygems/commit/17499cb83f

https://github.com/rubygems/rubygems/commit/a8d14c1fc2

DSLError prints the specific line in a Gemfile where the error was
raised. That's helpful when the error was explicitly raised by the
Gemfile DSL or, in the case it's implicitly raised, when the offending
code lives right in the Gemfile.

If it's an internal error, or something buried dowm in user code called
from the Gemfile, `DSLError` is not helpful since it hides the actual
culprit.

This commit tries to only raise `DSLError` in the cases mentioned above
and otherwise let the original error be raised.

https://github.com/rubygems/rubygems/commit/b30ff5a682

Things like OOM, or StackOverflow should be raised immediately.

https://github.com/rubygems/rubygems/commit/11691ce492

https://github.com/rubygems/rubygems/commit/b4ecb66224

https://github.com/rubygems/rubygems/commit/ab44fa9ee4