From: "Eregon (Benoit Daloze) via ruby-core" Date: 2024-09-17T12:37:03+00:00 Subject: [ruby-core:119236] [Ruby master Feature#20309] Bundled gems for Ruby 3.5 Issue #20309 has been updated by Eregon (Benoit Daloze). vo.x (Vit Ondruch) wrote in #note-35: > I don't think it is bad idea to start using `bundle install --local`, i.e. use gems which are already available on the system. And on top of that, stop using Bundler in containers for runtime in production use. Do you mean `--prefer-local`? I don't think `--local` would work in general since that does not attempt to connect to rubygems.org at all. >From the docs it's not clear if either of them would reuse bundled gems: ``` --local Do not attempt to connect to rubygems.org. Instead, Bundler will use the gems already present in Rubygems' cache or in vendor/cache. Note that if an appropriate platform-specific gem exists on rubygems.org it will not be found. --prefer-local Force using locally installed gems, or gems already present in Rubygems' cache or in vendor/cache, when resolving, even if newer versions are available remotely. Only attempt to connect to rubygems.org for gems that are not present locally. ``` + the version would need to match the bundled gem version in the Gemfile.lock, which I'm not sure there is any easy way to do that. But it would be nice, yeah, for Bundler to have a way to reuse bundled & default gems when possible, at resolution (`bundle lock`) and install time. ---------------------------------------- Feature #20309: Bundled gems for Ruby 3.5 https://bugs.ruby-lang.org/issues/20309#change-109819 * 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/