[ruby-core:111884] [Ruby master Bug#19351] Promote bundled gems at Ruby 3.3

Issue #19351 has been updated by Eregon (Benoit Daloze).


vo.x (Vit Ondruch) wrote in #note-3:
> BTW I don't think there would be that much fixing needed after all.

As we have seen with the `mail` gem, it can be a [huge](https://github.com/mikel/mail/pull/1439) [pain](https://github.com/mikel/mail/pull/1472) to move from default gem to bundled gem (in that case for `net-*` gems).

**What is the advantage to move from default gem to bundled gem?**
In both cases it's shipped with Ruby and they can be updated.
So it seems the only difference is the disadvantage to break every script using one of these libraries and Bundler by forcing to add them in the Gemfile (which typically doesn't work for older Ruby versions so adds many complications).

Please also consider the concerns in #18567.
Quoting them here:
> There are however multiple unwanted side effects of this:
> 
> 1. Removing gems from stdlib (e.g., #17873) is a breaking change, which makes upgrading to a new Ruby version more difficult.
>    I think this should only be done if there is a clear gain.
>    Being a default gem is already enough to fix a security issue without a CRuby release.
> 2. When any gem depends on a default gem, it tends to break on all Ruby implementations except CRuby, and for older Ruby versions.

1) is the same as I just said, but makes it clear this change hurts adopting new Ruby versions.

2) is a very important requirement if we do this, to ensure it works on JRuby/TruffleRuby before publishing the gem.
Replacing the implementation of a default gem (on JRuby/TruffleRuby) is only an issue if people depend on it explicitly. But for bundled gems it doesn't work at all.
So we need to ensure those gems work on JRuby/TruffleRuby, or we need time so JRuby/TruffleRuby can fix that *before* the gem is published/people add a dependency on it.

----------------------------------------
Bug #19351: Promote bundled gems at Ruby 3.3
https://bugs.ruby-lang.org/issues/19351#change-101299

* Author: hsbt (Hiroshi SHIBATA)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
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
optparse
observable
resolv
resolv-replace
rinda
un
fcntl
nkf
syslog
win32ole
```

### 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
date(datetime)
racc
```

and gems maintained by @kou 

```
csv
strscan
fiddle
stringio
```

But if we promote them to bundled gems, many of users need to add `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 -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/