Issue #20309 has been updated by Eregon (Benoit Daloze). @hsbt What about [yaml](https://github.com/ruby/yaml/blob/master/lib/yaml.rb) and [readline](https://github.com/ruby/readline/blob/master/lib/readline.rb)? I think these are not worth moving to bundled gems, i.e. the gains are (AFAIK) very small while the costs and confusion are high. I think so because the code for these 2 trivial "loaders/wrappers" (see links above) almost never changes (so the overhead of keeping them in sync is basically 0, probably 0 security issues in that code, etc). There seems to be no value to use track `readline` 0.0.4 vs `readline` 0.0.5 in a Gemfile.lock for instance, as the only likely changes would be to adapt to some incompatible change in Ruby, and then that's useless since the right version would be shipped with Ruby. The main problem there/my main concern is the cost, many people would need to add `gem "readline"` or `gem "yaml"` to their Gemfile for Ruby 3.5, and gain basically nothing from it, so it would be almost pure overhead. Also depending on `gem "yaml"` alone is not a good idea, because it doesn't mean any specific major version of `psych`. So one needs `gem "psych"` anyway, and the `gem "yaml"` is redundant. To try to quantify that I looked at * https://rubygems.org/gems/readline/reverse_dependencies: only 5 gems depend on readline right now. Yet there are 371+1158 matches for `gem-codesearch 'require "readline"'`+`gem-codesearch "require 'readline'"`. All these gems would need to add `gem "readline"`, for no gain. * https://rubygems.org/gems/psych/reverse_dependencies vs https://rubygems.org/gems/yaml/reverse_dependencies. There are about 18x (54M/3M) as much downloads for `psych` than `yaml`. RubyGems.org doesn't show a total count for reverse dependencies but it seems clear few gems depend on `yaml`, much much more depend on `psych`. All the gems depending on `psych` and not `yaml` would need changes. One more thing, as far as I can see, `psych` is a default gem. Having `yaml` as a bundled gem while `psych` is a default gem would lead to an awkward situation that when run under bundler and not adding either to the Gemfile, one can `require "psych"` but cannot `require "yaml"`. So they could use `Psych` in code but not `YAML` which feels a wrong limitation (people might just do YAML=Psych themselves as a workaround, but then that could cause warnings). So it seems clear `yaml` shouldn't become bundled gem before `psych` at least. And I think psych cannot become a bundled gem because RubyGems needs it. ---------------------------------------- Feature #20309: Bundled gems for Ruby 3.5 https://bugs.ruby-lang.org/issues/20309#change-107248 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I propose migrate the following default gems to bundled gems at Ruby 3.5. So, It means users will get warnings if users try to load them. (Update with 2024/03/14) * ostruct * I make ostruct as optional on json at https://github.com/flori/json/pull/565 * logger * activesupport needs to add logger to its dependency same as bigdecimal, drb or etc. * fiddle * pstore * win32ole I have a plan to migrate the following default gems too. But I need to more feedback from other committers about them. * irb * We need to consider how works `binding.irb` after Ruby 3.5. * I consider to use `irb` without Gemfile. * reline * readline (wrapper file for readline-ext and reline) * io-console * rubygems uses that. Should we make optional that? * open-uri * yaml (wrapper file for psych) * syck is retired today. I'm not sure what people uses `psych` directly, not `yaml`. * rdoc * We need to change build task like download rdoc gem before document generation. * extract `make doc` from `make all` and invoke `make doc` before `make install`. * or We make document generation is optional from Ruby 3.5 * We explicitly separate `make install` and `make install-doc` * un * `ruby -run` is one of cool feature of Ruby. Should we avoid uninstalling `un` gem? * mkmf uses `ruby -run` for that. I need to investigate that. * singleton * This is famous design pattern. Should we enforce users add them to their Gemfile? * forwadable * `reline` needs to add forwardable their `runtime_dependency` after migration. * weakref * I'm not sure how impact after migrating bundled gems. * fcntl * Should we integrate these constants into ruby core? I would like to migrate `ipaddr` and `uri` too. But these are used by webrick that is mock server for our test suite. We need to rewrite `webrick` with `TCPSocker` or extract `ipaddr` and `uri` dependency from `webrick` Other default gems depend on our build process or other libraries deeply. I will update this proposal if I could extract them from default gems. -- https://bugs.ruby-lang.org/