- If the user doesn't have `HOMEBREW_DEVELOPER` or
`HOMEBREW_NO_INSTALL_FROM_API` set but does have `homebrew/core` or
`homebrew/cask` taps installed this can cause problems with installing
outdated software.
- Hence, warn them in `brew doctor` if they have either of these taps
installed, with instructions on how to remove them.
Since we use `REXML::Document` in the type signature for `#parse_xml`,
we can encounter an `uninitialized constant
Homebrew::Livecheck::Strategy::Xml::REXML` error in strategies like
`Sparkle` that use `Xml#parse_xml` internally when the Sorbet runtime
is used. Moving the related require outside of the `#parse_xml` method
and into the `Xml` strategy proper resolves this issue.
`content` can be `nil` when a request doesn't succeed but
`#versions_from_content` expects a `String` value, so we need to
guard against a `nil` value like we do in other strategies.
The existing way of passing values to `#find_versions` methods in
strategies leads to type issues when the Sorbet runtime is enabled.
We've also recently talked about moving away from nilable args when
we can specify a default value but this doesn't work if we pass in a
`nil` value (like we're currently doing).
This commit aims to address both of those areas by better controlling
which arguments we're passing to `#find_versions`. This approach
naively handles `cask`/`url` arguments by special-casing
`ExtractPlist`.
However, we should be checking the strategy's `#find_versions`
method for a `cask` or `url` keyword parameter. The issue is that
`strategy.method(:find_versions).parameters` is returning
`[[:rest, :args], [:block, :blk]]` instead of the actual parameters
like `[[:keyreq, :url], [:key, :regex], [:keyrest, :unused],
[:block, :block]]`.
With sudoers one may override default sudo user. This mostly works
provided the admin configured the replacement appropriately. However
there are exceptions that absolutely must be run by root such as
/usr/sbin/installer and, under certain circumstances, /bin/launchctl.
- These were `Enabled: false` for the whole group of Rails cops, so my
removing the `Enabled: true` cops (what I thought was "redundant"
config in the previous commit) meant the specific ones we wanted to
use weren't enabled at all.
- Instead, let's reverse that by unsetting `Enabled: false` for the
whole group, and then disabling the specific cops with offenses that
we haven't got around to deciding if we care about yet.
- `EnabledByDefault` is a feature of RuboCop that enables all cops even
those marked `Enabled: false` in core RuboCop.
- I went through and disabled all the cops with offenses from this
config change. This way we can do a piecemeal approach to enabling
cops with offenses, while getting the benefits of the new cops with
no offenses.
- It is intentional that `brew style` comes back green here and there
are no code style fixes.
