brew
brew copied to clipboard
Homebrew
build(deps-dev): bump json_schemer from 2.1.1 to 2.2.1 in /Library/Homebrew
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: https://github.com/davishmcclurg/json_schemer/commit/d52c130e9967919c6cf1c9dbc3f0babfb8b01cf8
- Support custom keywords in nested schemas: https://github.com/davishmcclurg/json_schemer/commit/93c85a5006981347c7e9a4c11b73c6bdb65d8ba2
- Stringify instance location for custom keywords: https://github.com/davishmcclurg/json_schemer/commit/513c99130b9e7986b09881e7efd3fb7143744754
- Reduce unhelpful error output in
unevaluatedkeywords: 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
Configurationobject: davishmcclurg/json_schemer#170- Symbol key property defaults with
insert_property_defaults: :symbol: https://github.com/davishmcclurg/json_schemer/commit/a72473dc84199107ddedc8998950e5b82273232a- Consistent schema type support for schema validation methods: https://github.com/davishmcclurg/json_schemer/commit/bbcd0cea20cbaa61cf2bdae5f53840861cae54b8
- Validation option support for schema validation methods: https://github.com/davishmcclurg/json_schemer/commit/2eeef77de522f127619b7d0faa51e0d7e40977ad
Commits
743f1fe2.2.1002633bMerge pull request #180 from davishmcclurg/compare-instance-locations-by-iden...8be18dfSkip Ruby head on CI (ubuntu and macos)b92e1c2Compare property default instance locations by id9321f1aRemove newline under frozen string comment220dc4fFix workflow badge6ff7f26Revert "Upgrade minitest"2d6dc3aUpgrade minitestf0cc47e2.2.0 release date67c52f0Merge 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 rebasewill rebase this PR -
@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it -
@dependabot mergewill merge this PR after your CI passes on it -
@dependabot squash and mergewill squash and merge this PR after your CI passes on it -
@dependabot cancel mergewill cancel a previously requested merge and block automerging -
@dependabot reopenwill reopen this PR if it is closed -
@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually -
@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency -
@dependabot ignore this major versionwill 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 versionwill 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 dependencywill 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.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
@Bo98 Note: this is exactly the same issue I was hitting when trying to add base64 to the Gemfile in https://github.com/Homebrew/brew/pull/17315.
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.
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.
Have opened https://github.com/Homebrew/brew/pull/17343 and https://github.com/Homebrew/brew/pull/17342 to start working around this stuff and get this PR merged.
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: 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
Not using
bootsnapby 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
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.lockchanging): 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.
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
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?
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
Having
bundle cleanin vendor-gems and keeping the existing one in utils/gems.rb will likely be sufficient, given the issues is caused by--standaloneand 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)