summaryrefslogtreecommitdiff
path: root/tool/bundler/vendor_gems.rb
AgeCommit message (Collapse)Author
2025-11-18Fixed conflict of vendor_gems.rbHiroshi SHIBATA
2025-11-18Downgrade net-http 0.7.0 because JRuby is not workingHiroshi SHIBATA
2025-11-18Use released version of net-http-0.8.0Hiroshi SHIBATA
2025-10-23[ruby/rubygems] Bump up vendored uri to 1.0.4Hiroshi SHIBATA
https://github.com/ruby/rubygems/commit/bc77ec0bf2
2025-07-30[rubygems/rubygems] Bump vendored thor to 1.4.0David Rodríguez
https://github.com/rubygems/rubygems/commit/8078a747b3
2025-07-10[rubygems/rubygems] Update vendored resolv to 0.6.2Hiroshi SHIBATA
https://github.com/rubygems/rubygems/commit/afbbc02763
2025-05-14[rubygems/rubygems] Update vendored version and patch for net-http and ↵Hiroshi SHIBATA
net-http-persistent https://github.com/rubygems/rubygems/commit/b9a4722d5e
2025-03-27[rubygems/rubygems] Implement pub_grub strategy interfaceHartley McGuire
My application spends more than 30% of time during `bundle update` comparing versions due to versions being sorted inside next_package_to_try. This has been addressed in pub_grub by defining a strategy interface (a `#next_package_and_version` method) which allows consumers to have finer control over the heuristic to select the next package to try. This commit implements the new strategy interface to remove extraneous version sorting (previously in next_package_to_try) since only the final count of versions is used. Combined with a previous change to pub_grub (already applied to Bundler), this commit results in `bundle update` taking only half the time it did on 2.6.5. https://github.com/rubygems/rubygems/commit/62f69e27f0
2025-03-24[rubygems/rubygems] Update vendored pub_grubHartley McGuire
https://github.com/rubygems/rubygems/commit/3aaa75e7b9 Notes: Merged: https://github.com/ruby/ruby/pull/12968
2025-03-03[rubygems/rubygems] Update vendored uri to 1.0.3Hiroshi SHIBATA
https://github.com/rubygems/rubygems/commit/176dc7421c Notes: Merged: https://github.com/ruby/ruby/pull/12840
2024-12-18Bump vendored securerandom to 0.4.1David Rodríguez
2024-12-18Bump vendored timeout to 0.4.3David Rodríguez
2024-12-17Bump vendored resolv to 0.6.0David Rodríguez
2024-12-13Bump vendored uri to 1.0.2David Rodríguez
2024-12-13Bump vendored net-http to 0.6.0David Rodríguez
2024-12-13Bump vendored securerandom to 0.4.0David Rodríguez
2024-11-14Update vendored thor to 1.3.2David Rodríguez
2024-11-14Update vendored timeout to 0.4.2David Rodríguez
2024-11-14Update vendored securerandom to 0.3.2David Rodríguez
2024-11-14Update vendored resolv to 0.5.0David Rodríguez
2024-11-14Update vendored net-http to 0.5.0David Rodríguez
2024-11-14Update vendored fileutils to 1.7.3David Rodríguez
2024-11-14Update vendored optparse to 0.6.0David Rodríguez
2024-11-11Bump vendored uri to 1.0.1David Rodríguez
2024-10-10Update vendored net-httpSamuel Giddins
Signed-off-by: Samuel Giddins <segiddins@segiddins.me> Notes: Merged: https://github.com/ruby/ruby/pull/11860
2024-09-03Fix `gem exec rails new foo` failing on Ruby 3.2David Rodríguez
The default version of securerandom (0.2.2) gets activated by RubyGems, but does not match Rails requirements (>= 0.3), leading to an error like this: ``` $ gem exec rails new repro /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:2246:in `raise_if_conflicts': Unable to activate activesupport-7.2.1, because securerandom-0.2.2 conflicts with securerandom (>= 0.3) (Gem::ConflictError) from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1383:in `activate' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1421:in `block in activate_dependencies' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1403:in `each' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1403:in `activate_dependencies' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:1385:in `activate' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/core_ext/kernel_gem.rb:62:in `block in gem' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/core_ext/kernel_gem.rb:62:in `synchronize' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/core_ext/kernel_gem.rb:62:in `gem' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/exec_command.rb:193:in `activate!' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/exec_command.rb:73:in `execute' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:326:in `invoke_with_build_args' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:255:in `invoke_command' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:194:in `process_args' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:152:in `run' from /Users/deivid/Code/rubygems/rubygems/lib/rubygems/gem_runner.rb:56:in `run' from /Users/deivid/code/rubygems/rubygems/exe/gem:12:in `<main>' ``` Vendoring our own securerandom fixes the issue since that way we avoid activating the gem internally.
2024-03-27Update vendored resolv to 0.4.0Hiroshi SHIBATA
2023-12-15[rubygems/rubygems] Refactor vendoring to allow validating vendoring is ↵Samuel Giddins
reproducible Helps ensure that unsuspecting diffs to the vendored code arent accidentally introduced https://github.com/rubygems/rubygems/commit/7c425d49dd
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-26 22:24:13 +0000