[ruby-core:112049] [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-16:
> It makes to leave out-of-sync status with published gem like #18169. I'm checking ALL diffs and commits of ruby/* repos every day for resolving this issue after #18169 requests. Example for https://github.com/ruby/ruby/pull/7025. 

My understanding is this is fully automated now, i.e., a commit to the ruby/some_default_gem repo is immediately applied to ruby/ruby and vice-versa.
So it seems imopossible to get out of sync, isn't it?

> And we can add new maintainer easily different with ruby/ruby repo. In fact, `net-smtp`, `net-imap`, `rexml` and etc are maintained and released by maintainer's convenience.

The only constraint there is to have a new version number at ruby/ruby release time for those gems, right?
That can be done by just bumping the patch version or so of such gems in ruby/ruby, isn't it?

I think the pain of everyone using Ruby to change these gems from default to bundled gems is not worth those advantages.
At least things which don't use Bundler should not be impacted, e.g. `ruby -rbenchmark -e 'p Benchmark.realtime { ... }'`.

Also it seems the main motivation is #18169.
I think #18567 is far more problematic in practice for other Ruby implementations.
So like I said in https://bugs.ruby-lang.org/issues/18567#note-30, if we move anything to default/bundled gems, please make sure it works on JRuby/TruffleRuby by adding them in CI and defaulting to stdlib unless it works as-is (details described there).

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

* 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 -- [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/