Feature #20859
openMake Base64 to core class
Description
From https://bugs.ruby-lang.org/issues/20857#note-12
I also heard that base64
gem has some issue for eco-system like https://github.com/ddnexus/pagy/pull/618. My fist intention is simply added base64
gem into gem dependency by Gem::Specification#add_dependency
. But some people rewrite Base64.encode64
to Array#pack
.
It means gemification of base64
is miss-direciton by me. I withdraw that and propose to make Base64
into core class.
https://github.com/ruby/ruby/pull/11977
It resolve dependency issues of base64
as the default gems.
TODO:
- To release new version of
base64
gem that skip to load ifBase64
is available. - make
require "base64"
same asrequire "enumerator"
Updated by hsbt (Hiroshi SHIBATA) 4 days ago
- Related to Bug #20857: Ruby 3.4 seems to have backwards compatibility issues more than its predecessors added
Updated by hsbt (Hiroshi SHIBATA) 4 days ago
- Related to Feature #20187: Bundled gems at Ruby 3.4 added
Updated by vo.x (Vit Ondruch) 4 days ago
Just FTR, some usage of base64 was already removed, but I think that other projects already added the base64 dependency (or are about to add it 1).
Updated by nobu (Nobuyoshi Nakada) 4 days ago
Why make it built-in all at once, rather than moving it back to the standard library?
Updated by byroot (Jean Boussier) 4 days ago
I also think the general sentiment about this extraction is that the dependency is too small to justify adding it. For most users it's pretty much a one liner.
That said, is there a problem in just keeping it as a "default gem"? Now that it has a ::VERSION
constant etc, seems like the simplest thing to do.
Updated by deivid (David RodrÃguez) about 18 hours ago
I think these are two separate issues, so maybe better implement/discuss in two separate steps?
- One would be something like "Making
base64
a bundled gem caused too much trouble, let's revert that". This seems straightforward to fix. - Another one would be something like "Base64 is too small and basic to justify being a gem and not just a core builtin class". This seems more tricky and would involve moving it to a core class, making the gem a noop if the core class exists as @hsbt (Hiroshi SHIBATA) suggested, and I guess printing some deprecation warning in this case, so that the explicit dependency is removed?