From: "Eregon (Benoit Daloze) via ruby-core" Date: 2023-01-27T11:01:01+00:00 Subject: [ruby-core:112078] [Ruby master Feature#19351] Promote bundled gems at Ruby 3.3 Issue #19351 has been updated by Eregon (Benoit Daloze). hsbt (Hiroshi SHIBATA) wrote in #note-19: > No. some of commits conflicts usually. and some of people push `ruby/ruby` directly for fixing CI failure, not `ruby/*` repo. So, we are always out-of-sync status without my work. I remember some commit I made, maybe in `ruby/some_gem` being immediately committed to ruby/ruby too. So maybe that automatic cherry-picking is only in one direction, not the other, and maybe only for some gems and not all? > Because you didn't work release work of CRuby. Release team easily released [new version of CGI](https://www.ruby-lang.org/en/news/2022/11/22/http-response-splitting-in-cgi-cve-2021-33621/) without Ruby releases. Release team always spent over 6 hours with 5-6 people for security release of Ruby. We really hope to leave this hard work. Correct me if I'm wrong, but to fix a security issue in a bundled or default gem it's the same, there is no need to release CRuby, only to release the gem, isn't it? Maybe a CRuby release is considered for some default gems/big security issue because it's harder for users to find out about the security issue (e.g., dependabot won't tell them)? But then they would also need to find about the new CRuby release, given it's the same channel (https://www.ruby-lang.org/ announcements) it doesn't seem to help much, except for ruby installed by package manager maybe (rare for Ruby applications). ---------------------------------------- Feature #19351: Promote bundled gems at Ruby 3.3 https://bugs.ruby-lang.org/issues/19351#change-101512 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- In Ruby 3.2, the default gems and bundled gems are changed only adding `syntax_suggest`. I and some committers are considering promote default gems to bundled gems again for Ruby 3.3+. We hope to keep the current developer experience with dependency resolution and ignore the additional work like "Put gem "xxx" into your Gemfile" for developers. ### Proposal We propose the following libraries will promote default gems to bundled gems at Ruby 3.3. They are not the dependencies of Rails and RubyGems/Bundler. ``` abbrev getoptlong observable resolv resolv-replace rinda un fcntl (C-ext) nkf (C-ext) syslog (C-ext) win32ole (C-ext) ``` Update: I removed `optparse` from above list. ``` optparse: Used by Ruby build process ``` ### Additional works I also propose to promote rails dependencies without rubygems/bundler deps: ``` base64 benchmark delegate drb forwardable ipaddr irb mutex_m ostruct rdoc singleton tsort weakref bigdecimal (C-ext) date(datetime) (C-ext) racc (C-ext) ``` and gems maintained by @kou ``` csv ``` Following gems also maintained by @kou, but they are used on RubyGems/Bundler or MJIT. Maybe, We couldn't promote them because RubyGems/Bundler couldn't bundle C-ext gems. ``` fiddle (C-ext): used by MJIT stringio (C-ext) used by RubyGems/Bundler strscan (C-ext) used by RubyGems/Bundler ``` But if we promote them to bundled gems, many of users need to add like `gem "csv"` into their Gemfile. I'm considering to avoid this situation. Can we the specific feature of bundled gems to RubyGems or Bundler? Example, bundler have allowed list for bundled gems. So, listed gems could be require without Gemfile under the bundle exec. -- 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/postorius/lists/ruby-core.ml.ruby-lang.org/