We recently updated the `Pypi` strategy to use the PyPI JSON API and
the default strategy behavior no longer relies on a regex, so the initial implementation didn't include regex handling. This restores
support for a `livecheck` block regex by updating the `DEFAULT_BLOCK`
logic to handle an optional regex. This allows us to use a regex to
omit parts of the `info.version` value without having to duplicate
the default block logic in a `strategy` block only to use a regex.
This isn't currently necessary for any existing formulae using the
`Pypi` strategy but we have a few that needed a custom regex with
the previous strategy approach, so they may need this functionality
in the future. Besides that, restoring regex support to `Pypi`
ensures that `livecheck`/`strategy` blocks work in a fairly
consistent manner across strategies.
This updates the block-handling logic in `Json::versions_from_content`
to naively pass the regex value when the block has two parameters. Up
to now, we have been ensuring that `regex` is not `nil` and this
makes sense with existing usage (the `Crate` strategy's default
block, formulae/cask `strategy` blocks). However, we need to allow a
`nil` `regex` value to make it possible to add an optional `regex`
parameter in the `Pypi::DEFAULT_BLOCK` Proc. This is necessary to
allow the `Pypi` strategy to work with an optional regex from a
`livecheck` block again [without creating an additional
`DEFAULT_BLOCK` variant with a regex parameter].
Among other things, the previous commit added a `provided_content`
paramter to `Pypi::find_versions`, so this takes advantage of that to
expand `Pypi` test coverage to 100%.
This reworks the new `Pypi` JSON API implementation to use
`Json::find_versions` in `Pypi::find_versions`, borrowing some of the
approach from the `Crate` strategy.
Besides that, this pares down the fields in the
`::generate_input_values` return hash to only `:url`, as we're not
using a generated regex to match version information in this setup.
This adds a `provided_content` parameter to `::find_versions` as part
of this process and I will expand the `Pypi` tests to increase
coverage (like the `Crates` tests) in a later PR. 75% of `Pypi` checks
are failing at the moment (with some returning inaccurate version
information), so the current priority is getting this fix merged in
the short-term.
This required:
- adding signatures/types where missing
- ensuring that we respect the signature of `Version.new`
- remove some non-Sorbet type checks
- fixing the exception in tests
- removing some tests now caught by Sorbet
- fixing `Formula#prefix` so it works as intended with correct type
usage
We need a way to escape systemd command lines properly as systemd treats
unrecognised escape sequences as separate literal characters. This helper
function does that.
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".
This expands test coverage for `BumpVersionParser`, bringing line
coverage to 100% and branch coverage to 95.45%. This is the best we
can do for branch coverage, as Sorbet will catch an invalid argument
type before the method is executed, so we can't exercise the method
in a test to get 100% coverage.
`brew bump` will check for PRs related to a package even if the
package version and livecheck version are the same. We're presumably
only interested in related PRs when the livecheck version differs, so
we can reduce GitHub API requests by skipping the check(s) when the
versions are equal. We use `bump` in `autobump` workflows, so this
should help with recent rate limiting issues (e.g., 3203 out of 3426
autobumped formulae were up to date in a recent run).
This also reworks the output for duplicate PRs, making it clear when
`bump` skipped checking PRs (as printing "none" would suggest that
PRs were checked) and only printing the "Maybe duplicate" information
when checked. This makes it a little easier to understand what `bump`
has done internally from the output.
- `reinstall` and `upgrade` no longer mark as installed on request,
with or without names specified, but preserve the version from the
tab instead
- default `install_on_request` to `false` rather than `true`
- only set installed in request in a tab if it's missing rather than
false
Co-authored-by: Michael Cho <michael@michaelcho.dev>
This was discussed a while back on Slack. The idea behind this is that
ignoring dependencies during `brew uninstall` makes it too easy to break
things, even for developers. Those who know what they are doing can, and
IMO should, always use the `--ignore-dependencies` flag.
