[ruby-core:118995] [Ruby master Feature#20309] Bundled gems for Ruby 3.5
From:
"Earlopain (A S) via ruby-core" <ruby-core@...>
Date:
2024-08-30 16:06:01 UTC
List:
ruby-core #118995
Issue #20309 has been updated by Earlopain (A S).
I guess I can share my opinion here.
There definitely is a benefit in bundling some gems, both from a ruby maintainer and security perspective. But with things like `benchmark`, `forwardable`, `singleton`, (or `base64`, `mutex_m` from the previous issue) I am hardpressed to actually include these into the dependency graph.
Many libraries depend on them, and usually the usage is trivial. For `base64`, it's just a different, though less beautifully named method invocation (if you don't use the url-safe variants). `singleton` and `forwardable` are what I would consider syntactic sugar. I'm not going to add a dependency just for that, I will instead forgoe the small ergonomics I'd gain and go with the manual solution.
Note this is purely from a library perspective. End consumers are free to do what they want but if I can do the same thing myself in maybe 1 or 2 lines more I'm just going to do that. From PRs I've opened against other projects, maintainers tend to agree. Adding a dependency just for that usually isn't justifiable.
----------------------------------------
Feature #20309: Bundled gems for Ruby 3.5
https://bugs.ruby-lang.org/issues/20309#change-109568
* 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)
* 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
I have a plan to migrate the following default gems too. But I need to more feedback from other committers about them.
* 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)
* 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 -- [email protected]
To unsubscribe send an email to [email protected]
ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/