This adds more type signatures to `MacOSRequirement` to move it closer
to `typed: strict`. There are a few areas that aren't quite clear to
me based on the code and existing tests, so I've done what I can at
the moment.
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.
This is currently behaving incorrectly when calling `trash.swift` fails
due to lack of permissions. In this instance, `trash.swift` prints
error: permissionDenied
to stdout, and this is incorrectly parsed as having successfully trashed
a file named `error` and another named ` permissionDenied`.
Let's fix this by ensuring that:
- any paths in `trashed` are in the `paths` that we wanted to trash in
the first place
- define `untrashable` by removing the `trashed` paths from `paths`
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 modified `Cask::DSL` to define instance variables in the
`#initialize` method and this involved some changes to the `language`,
`language_eval`, and `languages` methods. One of those was to
initialize `@language_blocks` to an empty hash instead of using a
`nil` default. I updated the related condition in the `language_eval`
method but I missed that `language_blocks` is used in `Cask::Auditor`
and it specifically relies on a false-y value to check if the variable
is set. An empty hash isn't false-y, so this is causing issues for
`brew audit`.
This updates the condition in `Cask::Auditor` to check for a non-empty
hash instead, which resolves the issue.
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`.
`#present?` is called on a `DependsOn` object in `Cask::DSL` and this
is seemingly deferred to the underlying hash object but Sorbet doesn't
understand this kind of `SimpleDelegator` magic. This adds `empty?`
and `present?` methods that explicitly interact with the hash in a
way that Sorbet can understand.
These are always output in CI for e.g. `brew fetch google-chrome` and
are completely unactionable by the user.
Ultimately this is not disabling any security checks, it's just changing
when a warning is output and unifying the logic with the other similar
warning.
We recently added `POST` request support to livecheck but related cask
checks are failing the `livecheck_https_availability` audit because it
calls `validate_url_for_https_availability` which calls
`Utils::Curl.curl_check_http_content` and that checks the URL using a
`GET` request. Adding `POST` request support to all of those methods
will take some work, so this adds a guard to skip the audit if the
`livecheck` block uses `post_form` or `post_json`. This isn't ideal
but it will allow us to add these `livecheck` blocks in the interim
time.
Co-authored-by: Douglas Eichelberger <d@eic.email>
