Issue #20309 has been updated by Eregon (Benoit Daloze). hsbt (Hiroshi SHIBATA) wrote:
* ostruct * I make ostruct as optional on json at https://github.com/flori/json/pull/565
+1 since ostruct is already kind of deprecated.
* irb * We need to consider how works `binding.irb` after Ruby 3.5.
Will that break `binding.irb` under `bundle exec`? If so that seems a major problem. I would think it would break it if `binding.irb` is implemented as e.g. `gem "irb"; require "irb"; binding.irb`.
* yaml (wrapper file for psych) * syck is retired today. I'm not sure what people uses `psych` directly, not `yaml`.
`psych` seems to be a default gem (and I guess will remain as so as a dependency of rubygems). If so, what is the advantage to make `yaml` a bundled gem? It's a [trivial wrapper](https://github.com/ruby/ruby/blob/master/lib/yaml.rb) so I don't see advantage to make bundled instead of default gem, only overhead (adding `gem "yaml"` in Gemfiles which has no value as this code almost never changes) and troubles. BTW I think most programs use `require "yaml"` instead of `require "psych"` and I think that's better as it is, psych is kind of an implementation detail, people want to load/dump YAML. It seems busy unproductive work to replace `require "yaml"` by `require "psych"` or to add `gem "yaml"` in Gemfiles, so I am very much against making `yaml` a bundled gem.
* readline (wrapper file for readline-ext and reline)
Is the intention to have people do `require "reline"` instead of `require "readline"`? It seems weird if people add `gem "readline"` to solve this, when `gem "reline"` would make much more sense. It's a [trivial wrapper](https://github.com/ruby/ruby/blob/master/lib/readline.rb), so I think making it a bundled gem creates more problems/overhead than it solves.
* un * `ruby -run` is one of cool feature of Ruby. Should we avoid uninstalling `un` gem?
`ruby -run` would still work if `un` is a bundled gem, so I think that's OK. Maybe RubyGems should ask confirmation/extra warning when uninstalling a bundled gem.
* singleton * This is famous design pattern. Should we enforce users add them to their Gemfile?
IMO not worth it, it's pretty [trivial code](https://github.com/ruby/ruby/blob/master/lib/singleton.rb) and too much overhead to ask users to add to Gemfile for something so basic.
* weakref * I'm not sure how impact after migrating bundled gems.
[weakref](https://github.com/ruby/ruby/blob/master/lib/weakref.rb) is very tightly bound to implementation details, such as `::ObjectSpace::WeakMap.new` on CRuby. The implementation is completely different on JRuby and TruffleRuby. It will cause problems to make this a bundled gem for alternative Ruby implementations. So I think it is not worth to make this a bundled gem. Also, that file is tiny and trivial, and had [very few changes](https://github.com/ruby/ruby/commits/master/lib/weakref.rb).
* fcntl * Should we integrate these constants into ruby core?
It seems low-level stuff so I think being behind a `require` is in general good. But between core and bundled gem I would prefer core. ---------------------------------------- Feature #20309: Bundled gems for Ruby 3.5 https://bugs.ruby-lang.org/issues/20309#change-107043 * 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. * ostruct * I make ostruct as optional on json at https://github.com/flori/json/pull/565 * irb * We need to consider how works `binding.irb` after Ruby 3.5. * reline * readline (wrapper file for readline-ext and reline) * io-console * logger * fiddle * pstore * open-uri * yaml (wrapper file for psych) * syck is retired today. I'm not sure what people uses `psych` directly, not `yaml`. * win32ole I have a plan to migrate the following default gems too. But I need to more feedback from other committers about them. * rdoc * We need to change build task like download rdoc gem before document generation. * 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? * 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/