Issue #19351 has been updated by deivid (David RodrÃguez).
Nice.
The way I see it, this warning would ideally detect whether the gem was loaded by library
code or application code. If loaded by application code, it would directly recommend to
add `gem "foo"` to the Gemfile as the proper solution. If loaded by library
code, it would recommend to bug library author to add the dependency to their gemspec, and
adding `gem "foo"` to the Gemfile as a temporary workaround to remove the
warning.
----------------------------------------
Feature #19351: Promote bundled gems at Ruby 3.3
https://bugs.ruby-lang.org/issues/19351#change-103858
* 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 for Ruby 3.3.0-preview2
I propose the following libraries will promote default gems to bundled gems at Ruby
3.3.0-preview2
```
abbrev
getoptlong
observable
resolv-replace
rinda
nkf (C-ext)
syslog (C-ext)
base64
drb
mutex_m
csv
```
Other default gems depends on `make test-all` or other standard libraries. It's hard
to promote in this time. And I submit a PoC of bypass feature for Bundler and bundled
gems:
https://github.com/rubygems/rubygems/pull/6811
This feature add `load_paths` defined by `Gem.bundled_gems` that is pair list of Gem name
and version under the Bundler environment. This mean user can `require` bundled gems like
`csv` without `gem "csv"` on Gemfile.
And we need to warn like "'csv' is loaded without Gemfile, add "gem
'csv'" in your Gemfile" in `require` or other place. I have no idea how
notice this yet.
----
### Proposal
I 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-replace
rinda
nkf (C-ext)
syslog (C-ext)
```
Update: I removed `optparse` and `un` from above list. Because they are used by Ruby build
process.
```
optparse
un
```
Update 2: I also removed the following libraries. `resolv` and `fcntl` are used by test of
Ruby internal like `test_io.rb`. And we don't have built process of C extension at
Windows platform. I gave up to extract `win32ole` in this time.
```
resolv
fcntl (C-ext)
win32ole (C-ext)
```
### Additional works
I also propose to promote rails dependencies without rubygems/bundler deps:
```
base64
drb
mutex_m
```
Update: `delegate` is used by `tempfile`. We need to keep `delegate` as default gems for
build process. and I added `reline` into above list.
Update 2: The following libraries used by tests of `ruby/ruby` and other libraries like
psych. I need to remove their dependency from `ruby/ruby`.
```
benchmark
forwardable
ipaddr
irb
reline
ostruct
rdoc
singleton
tsort
weakref
bigdecimal (C-ext)
date(datetime) (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
```
### Follow-up feature
But if we promote them to bundled gems, many of users need to add like `gem
"csv"` into their Gemfile. I'm considering avoiding this situation.
Can we introduce 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/