search

davishmcclurg / json_schemer

JSON Schema validator. Supports drafts 4, 6, 7, 2019-09, 2020-12, OpenAPI 3.0, and OpenAPI 3.1.
MIT License
408 stars 64 forks source link

Avoid need for Base64 gem at runtime #182

Closed Bo98 closed 6 months ago

Bo98 commented 6 months ago

This follows a common practice that's been adopted by the majority of the Ruby community: https://github.com/rubocop/rubocop/commit/b2b29da6406ed55fe42fe045435c29bed6635299, https://github.com/rack/rack/commit/696ed9e8f48053683a0a19fc68eb49f094c0efcb, https://github.com/lostisland/faraday/commit/9487833b426ad1c50d6d8a29d82601202a528c56, https://github.com/octokit/octokit.rb/commit/a787bf47377229688eea4b6c78b26b584f65595b.

The personal reason for my need for this is that bootsnap doesn't seem to work properly on Ruby < 3.4 when using base64, which is preventing me from using json_schemer 2.2.x:

<internal:/ruby/3.3.1/lib/ruby/3.3.0/rubygems/core_ext/kernel_require.rb>:37:in `require': cannot load such file -- /vendor/bundle/ruby/3.3.0/gems/base64-0.2.0/lib/base64.rb (LoadError)
    from <internal:/ruby/3.3.1/lib/ruby/3.3.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
    from /vendor/bundle/ruby/3.3.0/gems/bootsnap-1.18.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'

This is technically a Bundler/Bootsnap problem, but I felt it was worthwhile reducing the dependency tree here anyway.

Bo98 commented 6 months ago

macos-latest failure on Ruby 2.5 is expected since macos-latest now points to an arm64 runner: https://github.blog/changelog/2024-05-20-actions-upcoming-changes-to-github-hosted-macos-runners/.

Only Ruby >= 2.6 is supported there: https://github.com/ruby/setup-ruby/commit/e8677f0f3922a9e00e6238630ba7742af68b6ee8

davishmcclurg commented 6 months ago

Hi @Bo98—thanks for opening this!

If I understand correctly, base64 will still be bundled with Ruby in 3.4—though not as a default gem. I'm a bit sad to see code getting more confusing (ie, what does unpack1("m0") mean?) in order to remove a gem dependency that ships with Ruby. Do you know of any discussion around bundled gem use in libraries? Are library authors meant to avoid using them?

This is a pretty small change, though, so I'm ok merging it if it makes it easier to use the library.

Thanks for looking into that Ruby 2.5 failure—I'll clean that up as part of https://github.com/davishmcclurg/json_schemer/issues/178.

Bo98 commented 6 months ago

If I understand correctly, base64 will still be bundled with Ruby in 3.4—though not as a default gem. I'm a bit sad to see code getting more confusing (ie, what does unpack1("m0") mean?) in order to remove a gem dependency that ships with Ruby. Do you know of any discussion around bundled gem use in libraries? Are library authors meant to avoid using them?

Bundled gems are competely ignored with Bundler so the behaviour from Ruby 3.4 is it will be that base64 will be a dependency that is always downloaded from RubyGems. This already happens in some cases on 3.3 and earlier if the default gem doesn't exactly match the latest version of base64 hosted on RubyGems.

I'm OK to close this though if you prefer the extra dependency for readability.

davishmcclurg commented 6 months ago

Bundled gems are competely ignored with Bundler so the behaviour from Ruby 3.4 is it will be that base64 will be a dependency that is always downloaded from RubyGems. This already happens in some cases on 3.3 and earlier if the default gem doesn't exactly match the latest version of base64 hosted on RubyGems.

Oh I didn't realize that—thanks for the clarification.

I'm OK to close this though if you prefer the extra dependency for readability.

No, I think this is good if bundler treats it as a regular dependency. I'll merge. Thanks for the contribution!

davishmcclurg commented 6 months ago

This has been released in 2.3.0.