Feature #20859: Make Base64 to core class

• Status: Assigned
• Assignee: hsbt (Hiroshi SHIBATA)
• Target version: -

[hsbt (Hiroshi SHIBATA)]

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 if Base64 is available.
• make require "base64" same as require "enumerator"

[hsbt (Hiroshi SHIBATA)]

• Related to Bug #20857: Ruby 3.4 seems to have backwards compatibility issues more than its predecessors added

[hsbt (Hiroshi SHIBATA)]

• Related to Feature #20187: Bundled gems at Ruby 3.4 added

[vo.x (Vit Ondruch)]

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).

[nobu (Nobuyoshi Nakada)]

Why make it built-in all at once, rather than moving it back to the standard library?

[Eregon (Benoit Daloze)]

• Description updated (diff)

[byroot (Jean Boussier)]

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.

[deivid (David Rodríguez)]

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?