I previously expanded use of `typed: strict` in livecheck files but
the exception was `livecheck/strategy.rb`. This addresses the
`@strategies` type errors in that file and upgrades it to
`typed: strict`.
Co-authored-by: apainintheneck <apainintheneck@gmail.com>
This updates livecheck files to use `typed: script` where feasible.
The remaining exception is `livecheck/strategy.rb`, as I wasn't
able to figure out how to resolve the typing issues around the
`@strategies` variable (I tried a couple of approaches but couldn't
find a working solution). This includes changes to resolve the other
type errors in `strategy.rb` but leaves the file as `typed: true`
for now.
livecheck is returning an `Unable to get versions` error for the
`ansible-lint`, `aws-sam-cli`, and `pyqt-builder` formulae. These use
the `Pypi` strategy without a `livecheck` block, so they use the
generated regex from the strategy. The `Pypi` strategy matches the
version from the tarball link on the pypi.org package page but this
fails for these packages because the formula's `stable` tarball uses
hyphens in the filename (e.g., `ansible-lint-...`) but the current
tarball filename uses underscores (e.g., `ansible_lint-...`).
This addresses the issue by updating the strategy regex to replace
[escaped] `-` or `_` characters in the package name with `[_-]`, so
the regex will match regardless of the delimiter used in the formula
filename.
From the description of the `--extract-plist` option, it would seem
that the `ExtractPlist` strategy is only enabled when the option is
used. Instead, livecheck automatically enables the strategy if the
command is run on only one cask. This rewords descriptions of the
option to clarify the behavior.
When the `--extract-plist` option was added to livecheck, conditions
were added in `#run_checks` to skip casks using `ExtractPlist` if the
`--extract-plist` isn't used and the run involves multiple
formulae/casks. This integrates the skip into the `SkipConditions`
class.
@samford is working on the ability to specify custom UA (among other things)
in livecheck blocks; "retrying" will cease to be relevant
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
We discussed the idea of adding a livecheck strategy to check crate
versions years ago but decided to put it off because it would have
only applied to one formula at the time (and it wasn't clear that a
crate was necessary in that case). We now have a few formulae that
use a crate in the `stable` URL (`cargo-llvm-cov`, `pngquant`,
`oakc`) and another formula with a crate resource (`deno`), so
there's some value to the idea now.
I established a standard approach for checking crate versions in a
somewhat recent `pngquant` `livecheck` block update and this commit
reworks it into a strategy, so we won't have to duplicate that
`livecheck` block in these cases. With this strategy, we usually
won't even need a `livecheck` block at all.
Under normal circumstances, a regex and/or strategy block shouldn't
be necessary but the strategy supports them when needed. The response
from the crates.io API is a JSON object, so this uses
`Json#versions_from_content` internally and a `strategy` block will
receive the parsed `json` object and a regex (the strategy default or
the regex from the `livecheck` block).
This was not returning the full name correctly for e.g. anything in
Homebrew/homebrew-fonts.
While we're here, fix up a few other places where `tap.core_cask_tap?`
can be used more appropriately.
This refactors verbose code in the `Sparkle` strategy where we access
element text into a reusable `Xml#element_text` method, replacing
chained calls like `item.elements["title"]&.text&.strip&.presence`
with `Xml.element_text(item, "title")`.
`#element_text` is only used to retrieve the text of a child element
in the `Sparkle` strategy but it can also retrieve the text from the
provided element if the `child_path` argument is omitted (i.e.,
`Xml.element_text(item)`). This will allow us to also avoid similar
calls like `item.text.strip.presence` in the future.
We need to be able to replicate the `Sparkle` strategy's sorting
and filtering behavior in a related cask audit, so this extracts
the logic into reusable methods.
This also stores `item.minimum_system_version` as a `MacOSVersion`
object (instead of a string), so we can do proper version comparison
(instead of naive string comparison) wherever needed.
Sometimes appcasts contain empty elements/attributes and the `Item`
values end up as an empty string because of how they're handled in
`#items_from_content`. It's reasonable to expect that empty values
would be `nil` instead, so this adds `#presence` calls to ensure this
is the case.
Historically, the `Sparkle` strategy's `Item` struct has only
included basic values from the appcast that are commonly useful.
Over time we've selectively added/surfaced more values as we've
encountered outliers that require use of different values in a
`strategy` block.
We now need to use `minimumSystemValue`, so this expands the `Item`
struct to include any appcast value that we could conceivably want
to use in the future. This will hopefully save us from having to make
more modifications to the struct (and related tests) before we can
use a previously-unused value in a `strategy` block.
Ever since we started using this at runtime it's been polluting
the backtrace output. This makes it harder to debug errors and
increases the amount of info users have to paste into the box
when filing an issue.
This is a very direct approach. Essentially, we strip out
everything related to the `sorbet-runtime` gem whenever the top
line in the backtrace is unrelated to sorbet-runtime.
The hope is that this will allow errors related to sorbet to
be diagnosed easily while also reducing the backtrace size
for all other types of errors.
Sometimes it is useful to see the full backtrace though.
For those cases, we include the full backtrace when
`--verbose` is passed in and print a warning that the
Sorbet lines have been removed from the backtrace the
first time they are removed.
Note: This requires gems to be set up so that the call to
`Gem.paths.home` works correctly. For that reason, it must
be included after `utils/gems` which is included in
`standalone/load_path` already.
