- This is cleaner than vendoring a whole bunch of new gems and pinning `psych`.
- Thanks for the pointer, Bo!
- It doesn't work, though?
```
❯ brew tests --only=migrator --debug
Error: cannot load such file -- debug/debug.so
Warning: Removed Sorbet lines from backtrace!
Rerun with `--verbose` to see the original backtrace
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/lib/ruby/gems/3.1.0/gems/debug-1.6.3/lib/debug/frame_info.rb:16:in `require'
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/lib/ruby/gems/3.1.0/gems/debug-1.6.3/lib/debug/frame_info.rb:16:in `rescue in <module:DEBUGGER__>'
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/lib/ruby/gems/3.1.0/gems/debug-1.6.3/lib/debug/frame_info.rb:13:in `<module:DEBUGGER__>'
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/lib/ruby/gems/3.1.0/gems/debug-1.6.3/lib/debug/frame_info.rb:3:in `<top (required)>'
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/lib/ruby/gems/3.1.0/gems/debug-1.6.3/lib/debug/session.rb:31:in `require_relative'
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/lib/ruby/gems/3.1.0/gems/debug-1.6.3/lib/debug/session.rb:31:in `<top (required)>'
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/lib/ruby/gems/3.1.0/gems/debug-1.6.3/lib/debug.rb:3:in `require_relative'
/opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/lib/ruby/gems/3.1.0/gems/debug-1.6.3/lib/debug.rb:3:in `<top (required)>'
/opt/homebrew/Library/Homebrew/dev-cmd/tests.rb:48:in `require'
/opt/homebrew/Library/Homebrew/dev-cmd/tests.rb:48:in `run'
/opt/homebrew/Library/Homebrew/brew.rb:89:in `<main>'
```
- Byebug was introduced in [2020](https://github.com/Homebrew/brew/pull/7577) for hooking into tests for debugging.
- It does not work anymore in so far as it does not stop at breakpoints when following the instructions to trigger them in tests.
Originally we were going to try and load the *flight blocks from the API
but we ended up going with downloading the caskfile for the subset of
casks that need this functionality for consisty's sake.
This reverts the following commits from most recent to oldest:
- ffc74a51fb32b66a4cd8bc41dbd076dd23d9100e
- e5616e94fe42505434c330be35eeafef2739944f
- d1490c3d5c087d00f2bca1787cce331202b195c5
- 7ca5a5d9a71a73f21bbb8555a38048f027bee89b
- 2d5d132713d0701d02d5ff33e9918812d13d2a83
It also changes how *flight blocks are handled in `.to_h`.
Essentially, when *flight blocks exist they are just included
as a hash of the artifact to nil to indicate that they exist.
More information isn't necessary since we don't evaluate
the current source code in the *flight artifacts that
we get from the API.
At the moment, `#use_homebrew_curl?` can only be true for a
`homepage` or `stable`/cask `url` with `using: :homebrew_curl`. If
the checked URL differs from these URLs, livecheck won't use brewed
curl. This limitation prevents livecheck from using brewed curl for a
`livecheck` block URL that's a string literal (not a symbol for a
`#checkable_url` like `:stable`, `:head`, `:url`). `libzip` was the
original formula referenced in the related brew issue and it meets
this criterion, so it doesn't appear to be handled by the existing
`#use_homebrew_curl?` implementation.
Additionally, the existing behavior can cause livecheck to
unnecessarily use brewed curl for a completely different website
(e.g., `cubelib`, `otf2`). For example, if the `stable` URL has
`using: :homebrew_curl` and the `livecheck` block has `url
:homepage`, livecheck will use brewed curl when checking the
`homepage`. If these are completely different domains/servers, it's
unlikely that we would need to use brewed curl when checking the
`homepage`, so this particular behavior may not be beneficial.
This commit reimplements `use_homebrew_curl?` to apply brewed curl
when the checked URL's root domain is the same as the root domain of
an aforementioned formula/cask URL with `using: :homebrew_curl`. For
example, this looser approach would allow a `livecheck` block
checking `https://www.example.com/downloads/` to use brewed curl if
the `stable` URL was `https://downloads.example.com/example.zip` with
`using: :homebrew_curl`. These could be different servers but, based
on related formulae, this looseness is necessary for the moment.
This approach aims to resolve both issues, allowing brewed curl to be
applied to a slightly broader range of URLs (i.e., not limited to
just the `#checkable_urls`) while also helping to avoid unnecessarily
applying brewed curl when it's less likely to be useful (completely
different domains). Neither approach is perfect but this one may be
more useful in the interim time.
Depending on how this looser approach works in practice, we may want
to consider returning to a stricter approach once we have something
like `using: :homebrew_curl` in `livecheck` blocks (this is
forthcoming). Being explicit in a `livecheck` block is the most
reliable approach (i.e., only use brewed curl when needed), so we
could favor that and pare down the automated approach to only what's
needed to support implicit checks (i.e., with no `livecheck` block).
Of course, it's also possible to drop the automated approach entirely
and simply require a `livecheck` block in this scenario but we can
decide on how to handle this when the time comes.
