This adds a `UsesOnSystem` class to `OnSystem`, containing boolean
instance variables to indicate which types of on_system methods are
used in a formula or cask. This is intended as a replacement for
`@on_system_blocks_exist`, which doesn't allow us to determine what
kinds of on_system calls were used. This provides more granularity
but we can still use `@uses_on_system.present?` to determine whether
any on_system calls were used (and this doubles as a `nil` check in
`Formula`, as the `self.class` instance variable has to use a nilable
type).
The `UsesOnSystem` instance variables cover the current
`ARCH_OPTIONS` and `BASE_OS_OPTIONS`. At the moment, we mostly need
to tell whether there are macOS/Linux or Intel/ARM on_system calls,
so I've omitted instance variables for specific macOS version until
we have a need for them.
As a practical example, if you wanted to determine whether a cask
uses Linux on_system calls, you can call
`cask.uses_on_system.linux?`. The `linux` boolean will be `true` if
the cask has an `on_linux` block, an `on_system` block (which requires
Linux), or uses `os linux: ...`. This is something that would be
challenging to determine from outside of `OnSystem` but it's
relatively easy to collect the information in `OnSystem` methods and
make it available like this.
I inadvertently duplicated the `@token` instance variable definition
in `Cask::DSL#initiailize`, so this removes the duplicate. This
didn't have any noticeable effect because it was redefined afterward,
so this is just a bit of tidying up.
I recently updated `Cask::DSL` to define instance variables in
`#initialize` to get us closer to resolving a "shape variation"
warning from Ruby. The reason why we continued to receive this warning
after the previous changes is because I overlooked the variables that
are set using `set_unique_stanza`.
The tricky part about those instance variables is that we need to be
able to identify if they've been set. I've handled this by using a
`nil` initial value and updating the `instance_variable_defined?`
condition to check for a non-`nil` value instead. This works for these
variables but it would be a problem if we ever have a DSL method that
accepts a `nil` argument.
We're now seeing warnings related to the cask DSL surfaced by Ruby
3.4:
```
/opt/homebrew/Library/Homebrew/cask/dsl.rb:456: warning: The class
Cask::DSL reached 8 shape variations, instance variables accesses
will be slower and memory usage increased.
It is recommended to define instance variables in a consistent order,
for instance by eagerly defining them all in the #initialize method.
```
I've been working on upgrading `Cask::DSL` to `typed: strict` and
part of that involves defining all of the instance variables in the
`initialize` method, so I've extracted this part of that work as a
way of helping to resolve the aforementioned warning. This doesn't
fully resolve the warning but it addresses what it was originally
referencing, at least.
For what it's worth, this includes some type fixes but I've only
included what's necessary to pass `brew typecheck`.
The existing code for handling a `HEAD`-only formula involves two
return values that can be `nil` but this isn't apparent because the
related methods aren't typed. This adds type signatures to the
methods and updates the livecheck code to account for `nil` return
values (making it clear which methods can return `nil`).
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
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
```
