Feature #20859
closedMake 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) 20 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) 20 days ago
- Related to Feature #20187: Bundled gems at Ruby 3.4 added
Updated by vo.x (Vit Ondruch) 20 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) 20 days ago
Why make it built-in all at once, rather than moving it back to the standard library?
Updated by byroot (Jean Boussier) 20 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) 17 days 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?
Updated by mame (Yusuke Endoh) 16 days ago
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.)
Updated by deivid (David Rodríguez) 15 days ago
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.
Updated by hsbt (Hiroshi SHIBATA) 15 days ago
- Status changed from Assigned to Rejected
Matz is negative for this proposal. I withdraw this.