summaryrefslogtreecommitdiff
path: root/test/ruby/test_thread_queue.rb
diff options
context:
space:
mode:
authorDavid Rodríguez <deivid.rodriguez@riseup.net>2024-11-05 17:55:41 +0100
committergit <svn-admin@ruby-lang.org>2024-11-07 10:03:54 +0000
commitffcfaf4ce4eba4975f6ef79bf4b6c898180107f2 (patch)
treef12945afd32234b5fe20aa0db9fcfa771fa50cd7 /test/ruby/test_thread_queue.rb
parentdf3395f2e301e7739dda5b7455e8c6b1c25b334d (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