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".
- Previously I thought that comments were fine to discourage people from
wasting their time trying to bump things that used `undef` that Sorbet
didn't support. But RuboCop is better at this since it'll complain if
the comments are unnecessary.
- Suggested in https://github.com/Homebrew/brew/pull/18018#issuecomment-2283369501.
- I've gone for a mixture of `rubocop:disable` for the files that can't
be `typed: strict` (use of undef, required before everything else, etc)
and `rubocop:todo` for everything else that should be tried to make
strictly typed. There's no functional difference between the two as
`rubocop:todo` is `rubocop:disable` with a different name.
- And I entirely disabled the cop for the docs/ directory since
`typed: strict` isn't going to gain us anything for some Markdown
linting config files.
- This means that now it's easier to track what needs to be done rather
than relying on checklists of files in our big Sorbet issue:
```shell
$ git grep 'typed: true # rubocop:todo Sorbet/StrictSigil' | wc -l
268
```
- And this is confirmed working for new files:
```shell
$ git status
On branch use-rubocop-for-sorbet-strict-sigils
Untracked files:
(use "git add <file>..." to include in what will be committed)
Library/Homebrew/bad.rb
Library/Homebrew/good.rb
nothing added to commit but untracked files present (use "git add" to track)
$ brew style
Offenses:
bad.rb:1:1: C: Sorbet/StrictSigil: Sorbet sigil should be at least strict got true.
^^^^^^^^^^^^^
1340 files inspected, 1 offense detected
```
- This skips over stanza names that are not overrideable in `on_*`
blocks, with the positive side effect that `on_*` blocks themselves
aren't in the list so we can get rid of another conditional.
- Stanzas overrideable in blocks are defined in `Cask::DSL` by each of
the methods calling `set_unique_stanza`.
- This came up in Cask `simply-fortran`:
```
Scanning /opt/homebrew/Library/Taps/homebrew/homebrew-cask/Casks/simply-fortran.rb
send_node: s(:send, nil, :arch), send_node.parent: s(:begin,
s(:send, nil, :arch)), send_node.parent.parent: (regexp
(str "href=.*?simplyfortran[._-]v?(\\d+(?:\\.\\d+)+)")
(begin
(send nil :arch))
(str "\\.dmg")
(regopt :i))
Casks/simply-fortran.rb:2:3: C: Cask/NoOverrides: Do not use a top-level arch stanza as the default. Add it to an on_{system} block instead.
Use :or_older or :or_newer to specify a range of macOS versions.
arch arm: "-arm64", intel: "-x86_64"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1 file inspected, 1 offense detected
```
- This passes the previously failing test for `on_*` blocks with
`livecheck` blocks with multiple stanzas inside them (eg `url` and
`strategy`) that weren't being correctly skipped because we weren't
detecting high enough up the ancestry.
- The Cask `sip`, to give a random example, was failing this RuboCop
because it has a `livecheck` block within an `on_*` block and the
livecheck block and the top-level Cask both have `url` stanzas. This
is a legitimate use of `livecheck` blocks because the cask software
download URL and the livecheck version check URL are not the same
thing, so let's skip over `livecheck` blocks and their contents.
- Otherwise syntax like this, where `#{arch}` is an interpolation,
causes an offense:
```ruby
cask "transcribe" do
arch arm: "_arm"
on_catalina :or_older do
version "8.75.2"
sha256 "f01781100cd3b9987c8f8892145a2eaa358df07b92e10e26f30b6a877f5b352c"
url "https://www.seventhstring.com/xscribe/downmo/transcribe#{version.no_dots}.dmg"
livecheck_version = "10"
end
on_big_sur :or_newer do
livecheck_version = "11"
version "9.21"
sha256 :no_check
url "https://www.seventhstring.com/xscribe/transcribe#{arch}.dmg"
end
[...]
end
```
```
Casks/transcribe.rb:2:3: C: Cask/NoOverrides: Do not use a top-level arch stanza as the default. Add it to an on_{system} block instead.
Use :or_older or :or_newer to specify a range of macOS versions.
arch arm: "_arm"
^^^^^^^^^^^^^^^^
1 file inspected, 1 offense detected
```
- In the event that there's only one common stanza within the `on_*`
blocks (eg, `url`) with a generic `version` that doesn't change per-OS,
let's not force adding `version` to each `on_*` block as well.
- As discussed in
https://github.com/Homebrew/brew/pull/14976#issuecomment-1474544569
and further comments, this is needed because in order to enforce the
order of `on_{arch,system}` blocks we need to have everything
consistently within one of those blocks.
- We previously allowed overrides where the top-level `version` stanza
would be the default, unless on an OS that had an `on_system` block
with a `version` specified. But this breaks down when we try to order
the `on_system` blocks because if a `url` at the top-level has a
`version` interpolated in it, then the `version` stanza needs to be
above the `url` stanza. But it could be that `version` is OS-specific.
- Let's stop allowing overrides and require that everything be in an
`on_system` block. This will make it easier to enforce the order of
`on_system` blocks in a future PR (14976).
