Feature #20859: Make Base64 to core class

• Status: Rejected
• 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?

[mame (Yusuke Endoh)]

My understanding is that default gems are transitional to eventually being promoted to bundled gems. So, I didn't think there was an option to make it a default gem permanently. As a matter of fact, mirroring repositories is a pain.

In terms of base64, it is not expected to add any features in the future, and it is quite unlikely that it will be even updated. (I am the current maintainer of base64 gem.) And it is a very small library.
Therefore, I do not think it is worth making it a bundled gem. I think it would be better to make it built-in or revert to the standard library (not a default gem).

(I am not opposed to reverting back to the default gem as a temporary measure, since we are close to release.)

[deivid (David Rodríguez)]

I agree with everything you said @mame (Yusuke Endoh). I didn't know the final goal of gemification of the standard library was to make all default gems either stdlib or bundled gems. I like that and I support it.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Assigned to Rejected

Matz is negative for this proposal. I withdraw this.