From: deivid via ruby-core Date: 2024-09-17T09:40:58+00:00 Subject: [ruby-core:119235] [Ruby master Feature#20309] Bundled gems for Ruby 3.5 Issue #20309 has been updated by deivid (David Rodr�guez). > I don't think so. Bundler should provide that feature for like debug, stackprof and irb. I and @mame (Yusuke Endoh) discussed about that. We sometimes need to use that tools without updating Gemfile and its lockfile. Yeah, that sounds reasonable to me, and you can already do that with default gems. My question is more, why does `irb` need to be converted into a bundled gem? I think the conversion does have a maintenance cost, so I want to make sure the benefits are worth that cost. If we still want to do this, can we add some test somewhere that `binding.irb` works in a `bundle exec` context, to make sure we don't break that code in `prelude.rb`? ---------------------------------------- Feature #20309: Bundled gems for Ruby 3.5 https://bugs.ruby-lang.org/issues/20309#change-109818 * 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, 2024/06/05, 2024/09/06) * rdoc(done) * 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`. * done for Ruby 3.4 * or We make document generation is optional from Ruby 3.5 * We explicitly separate `make install` and `make install-doc` * ostruct(done) * I make ostruct as optional on json at https://github.com/flori/json/pull/565 * pstore(done) * win32ole(done) * logger(done) * activesupport needs to add logger to its dependency same as bigdecimal, drb or etc. * fiddle(done) * benchmark * 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) I have a plan to migrate the following default gems too. But I need to more feedback from other committers about them. * 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`. * 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/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/