build(deps-dev): bump json_schemer from 2.1.1 to 2.2.1 in /Library/Homebrew

[dependabot]

Bumps json_schemer from 2.1.1 to 2.2.1.

Changelog

Sourced from json_schemer's changelog.

Changelog

2.2.0 - 2024-03-02

Bug Fixes

• Support symbol keys when accessing original instance: davishmcclurg/json_schemer@d52c130
• Support custom keywords in nested schemas: davishmcclurg/json_schemer@93c85a5
• Stringify instance location for custom keywords: davishmcclurg/json_schemer@513c991
• Reduce unhelpful error output in unevaluated keywords: davishmcclurg/json_schemer#164
• Handle parse errors during schema validation: davishmcclurg/json_schemer#171
• Follow refs when finding default property values: davishmcclurg/json_schemer#175

Features

• Global configuration with Configuration object: davishmcclurg/json_schemer#170
• Symbol key property defaults with insert_property_defaults: :symbol: davishmcclurg/json_schemer@a72473d
• Consistent schema type support for schema validation methods: davishmcclurg/json_schemer@bbcd0ce
• Validation option support for schema validation methods: davishmcclurg/json_schemer@2eeef77

Commits

• 743f1fe 2.2.1
• 002633b Merge pull request #180 from davishmcclurg/compare-instance-locations-by-iden...
• 8be18df Skip Ruby head on CI (ubuntu and macos)
• b92e1c2 Compare property default instance locations by id
• 9321f1a Remove newline under frozen string comment
• 220dc4f Fix workflow badge
• 6ff7f26 Revert "Upgrade minitest"
• 2d6dc3a Upgrade minitest
• f0cc47e 2.2.0 release date
• 67c52f0 Merge pull request #176 from davishmcclurg/2.2.0
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[p-linnane]

@dependabot recreate

[Bo98]

Thinking about this more, this does remind me of a bootsnap issue someone emailed me about recently that I've not managed to find the time to investigate yet. It's possible fixing that might fix this - I'll try find a free day to poke at that soon.

[p-linnane]

@dependabot recreate

[p-linnane]

@Bo98 Have you had time to poke at this?

[MikeMcQuaid]

@dependabot recreate

[MikeMcQuaid]

@Bo98 Note: this is exactly the same issue I was hitting when trying to add base64 to the Gemfile in #17315.

[MikeMcQuaid]

@dependabot recreate

[Bo98]

Yes, am aware. This behaviour is expected behaviour from Bootsnap as it expects gems installs to be stable. The only workaround here is manually removing the base64 install in vendor-gems, or asking upstream to drop the dependency which I will get to today.

[MikeMcQuaid]

This behaviour is expected behaviour from Bootsnap as it expects gems installs to be stable.

What does this mean?

The only workaround here is manually removing the base64 install in vendor-gems, or asking upstream to drop the dependency which I will get to today.

I think asking upstream to drop the dependency just kicks the can down the road here. It's going to be an issue with Ruby 3.4 or if we want to add base64 to the Gemfile earlier.

Not using bootsnap by default at least in our CI seems like a good idea.

[MikeMcQuaid]

Have opened #17343 and #17342 to start working around this stuff and get this PR merged.

[Bo98]

I think asking upstream to drop the dependency just kicks the can down the road here.

Not really when it's something very widely agreed on in the Ruby community: rubocop/rubocop@b2b29da, rack/rack@696ed9e, lostisland/faraday@9487833, octokit/octokit.rb@a787bf4

Not using bootsnap by default at least in our CI seems like a good idea.

CI is indicative that this would break locally too so not sure this is really a good idea.

What does this mean?

Bootsnap, for performance reasons, has a list of things that are deemed "stable" (i.e. don't randomly uninstall without the likes of Gemfile.lock changing): https://github.com/Shopify/bootsnap/blob/f627992c526423943115845bd5bfdfc01bd2ae3c/lib/bootsnap/load_path_cache/path.rb#L123-L133

[MikeMcQuaid]

Not really when it's something very widely agreed on in the Ruby community: rubocop/rubocop@b2b29da, rack/rack@696ed9e, lostisland/faraday@9487833, octokit/octokit.rb@a787bf4

Note that Octokit still adds it to the Gemfile.

I still consider it can-kicking to say "if a gem update requires e.g. base64 (or one of the other similar gems e.g. css) we cannot update to it until we convince upstream to drop the dependency".

Bootsnap, for performance reasons, has a list of things that are deemed "stable" (i.e. don't randomly uninstall without the likes of Gemfile.lock changing): Shopify/bootsnap@f627992/lib/bootsnap/load_path_cache/path.rb#L123-L133

Thanks for explaining.

To me: this is a pretty clear bug in Bundler that I'll report upstream. It cannot/should not be that bundle install and bundle install --standalone will install different gems and bundle install will unconditionally remove installed gems specified in the Gemfile even when BUNDLE_CLEAN=false.

[Bo98]

Note that Octokit still adds it to the Gemfile.

Yes but that's internal to them and not exposed to dependents.

To be clear: I expect us to vendor base64, for at the very least formula compatibility (and the URL-safe functions we use for JWS which are slightly more complex anyway). It's just a question of whether that will be Ruby 3.4 (which will have no issues as the default gem will be gone) or sooner when issues are addressed.

To me: this is a pretty clear bug in Bundler that I'll report upstream.

Yes, there's a PR open that I reckon will solve this: rubygems/rubygems#7673

[MikeMcQuaid]

Yes, there's a PR open that I reckon will solve this: rubygems/rubygems#7673

@Bo98 Great, seems like the best option here, good find.

Here's a thought: what if we pushed the bundle clean side to brew cleanup and brew vendor-gems instead?

[Bo98]

Having bundle clean in vendor-gems and keeping the existing one in utils/gems.rb will likely be sufficient, given the issues is caused by --standalone and the only occurrence of that is in vendor-gems. I can give it a try if you'd like

[MikeMcQuaid]

Having bundle clean in vendor-gems and keeping the existing one in utils/gems.rb will likely be sufficient, given the issues is caused by --standalone and the only occurrence of that is in vendor-gems. I can give it a try if you'd like

Yeh, good idea. May also want/need to edit https://github.com/Homebrew/brew/blob/master/Library/Homebrew/.bundle/config#L3

(which it took me far too long to find)

[Bo98]

@dependabot recreate

[MikeMcQuaid]

Great work, thanks @Bo98!