diff options
| author | David RodrÃguez <deivid.rodriguez@riseup.net> | 2024-11-05 17:55:41 +0100 |
|---|---|---|
| committer | git <svn-admin@ruby-lang.org> | 2024-11-07 10:03:54 +0000 |
| commit | ffcfaf4ce4eba4975f6ef79bf4b6c898180107f2 (patch) | |
| tree | f12945afd32234b5fe20aa0db9fcfa771fa50cd7 /test/ruby/test_thread_queue.rb | |
| parent | df3395f2e301e7739dda5b7455e8c6b1c25b334d (diff) | |
[rubygems/rubygems] Undeprecate Gemfiles without a global source
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
Diffstat (limited to 'test/ruby/test_thread_queue.rb')
0 files changed, 0 insertions, 0 deletions
