Remove deprecated base64 in favour of pack/unpack (2-2-stable) #2174
Conversation
The base64 library is external as of Ruby 3.4 and is no longer available by default in Ruby. The pack/unpack methods support encoding as base64 and can be used in it's place. String#unpack.first was preferred here to support Ruby 2.3, which didn't yet have String#unpack1 introduced in Ruby 2.4.
adam12
changed the title
|
I don't think we should backport this to 2.2 before backporting it to 3.0. It's also not a security issue, so it shouldn't be considered for backport to 2.2, IMO. |
adam12
force-pushed
the
2-2/base64-deprecation
branch
from
3ac24f9
to
2b301b4
Compare
|
To preface: I'm OK if this merges or if it doesn't. I actually hesitated to submit a PR to an older release branch, but I looked for the official stance on backports and didn't see anything (maybe I missed it?). If it's not acceptable for backport, we can go ahead and close the PR. I have 2 applications with a very sticky Rack 2 dependency that I am in the process of upgrading, but it's been a bit of a challenge and I still want to continue with Ruby upgrades. I'll end up maintaining my own fork of 2-2-stable if I have to. |
|
I just noticed that the |
|
I suppose we either need to do one of those options, or this release will simply stop working with the next major release of Ruby, no? |
|
It won't stop working, it will just require that users of Ruby 3.4+ and Rack 2.2 list base64 explicitly in their Gemfile. |
|
Right, so there is a workaround, which is users would need to explicitly add the missing gem to their application level gemfile. i.e. the Rack gem has an implicit dependency and the user can compensate for that. |
The base64 library is external as of Ruby 3.4 and is no longer available by default in Ruby. The pack/unpack methods support encoding as base64 and can be used in its place.
String#unpack.first was preferred here to support Ruby 2.3, which didn't yet have String#unpack1 introduced in Ruby 2.4.