- don't care about no checksums being defined for official casks
- don't complain about Gatekeeper being disabled on GitHub Actions as
it's been globally disabled for the team
This seems like it was a bug before the recent change to remove
OpenStruct from `Homebrew::CLI::Args` but it was failing silently
before. Now we pass the args to the `Cask::Info.info` method so
that when they eventually reach the `Utils::Analytics.output_analytics`
method they are present as expected.
Example error fragment:
```console
$ set -e HOMEBREW_NO_ANALYTICS
$ brew info iterm2 --cask --verbose
==> iterm2: 3.5.10 (auto_updates)
https://iterm2.com/
Installed
/usr/local/Caskroom/iterm2/3.5.4 (91.7MB)
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/i/iterm2.rb
==> Name
iTerm2
==> Description
Terminal emulator as alternative to Apple's Terminal app
==> Artifacts
iTerm.app (App)
Error: undefined method `analytics?' for an instance of Homebrew::CLI::Args
/usr/local/Homebrew/Library/Homebrew/utils/analytics.rb:248:in `output_analytics'
/usr/local/Homebrew/Library/Homebrew/utils/analytics.rb:342:in `cask_output'
/usr/local/Homebrew/Library/Homebrew/cask/info.rb:39:in `info'
```
This showed a confusing message when the trash path was able to be
deleted using sudo since the untrashable array was updated but
the check was higher up for returning early.
```
==> Trashing files:
/Users/Shared/Maxon
/Users/Shared/Red Giant
~/Library/Application Support/Maxon
~/Library/Application Support/Red Giant
~/Library/Caches/net.maxon.app-manager
~/Library/Preferences/Maxon
~/Library/Preferences/net.maxon.app-manager.plist
~/Library/Saved Application State/net.maxon.app-manager.savedState
==> Using sudo to gain ownership of path '/Users/Shared/Maxon'
==> Using sudo to gain ownership of path '/Users/Shared/Red Giant'
Warning: The following files could not be trashed, please do so manually:
==> Removing all staged versions of Cask 'maxon'
```
The warning about files not getting trashed should only be shown if
some files didn't get trashed.
Fixes https://github.com/Homebrew/brew/issues/18901
Formulae, casks, and resources have a `#livecheckable?` method that
indicates whether they contain a `livecheck` block. This is intended
to be read as "has a livecheckable?", not "is livecheckable?" (as
livecheck can find versions for some packages/resources without a
`livecheck` block). Unfortunately, correct understanding of this
method's behavior [outside of documentation] relies on historical
knowledge that few people possess, so this is often confusing to
anyone who hasn't been working on livecheck since 2020.
In the olden days, a "livecheckable" was a Ruby file containing a
`livecheck` block (originally a hash) with a filename that
corresponded to a related formula. The `livecheck` blocks in
livecheckable files were integrated into their respective formulae in
August 2020, so [first-party] livecheckables ceased to exist at that
time. From that point forward, we simply referred to these as
`livecheck` blocks.
With that in mind, this clarifies the situation by replacing
"livecheckable" language. This includes renaming `#livecheckable?` to
`#livecheck_defined?`, replacing usage of "livecheckable" as a noun
with "`livecheck` block", replacing "livecheckable" as a boolean with
"livecheck_defined", and replacing incorrect usage of "livecheckable"
as an adjective with "checkable".
We've already disabled installing casks/formulae from URLs and we
regularly tell people not to install from paths so let's just deprecate
this behaviour entirely.
Even Homebrew developers do not need to work this way.
The method only returned the executable name and not the full path,
leading to a swallowed error, because brew gracefully ignores a
failing lipo command.
Currently `brew audit` only audits the first binary in a cask.
For example the cask `wiso-steuer-2024` contains multiple binaries in
`Contents/MacOS`:
- `btssysteminfo`
- `whilfe`
- `wmain24`
The first binary (some telemetry tool) is not the main binary and not
a universal binary, but the other two are. Given that `wmain24` is
defined as the main binary in the `Contents/Info.plist`, brew probably
should audit that binary rather than just checking the first one.
