This seems like it was a bug before the recent change to remove
OpenStruct from `Homebrew::CLI::Args` but it was failing silently
before. Now we pass the args to the `Cask::Info.info` method so
that when they eventually reach the `Utils::Analytics.output_analytics`
method they are present as expected.
Example error fragment:
```console
$ set -e HOMEBREW_NO_ANALYTICS
$ brew info iterm2 --cask --verbose
==> iterm2: 3.5.10 (auto_updates)
https://iterm2.com/
Installed
/usr/local/Caskroom/iterm2/3.5.4 (91.7MB)
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/i/iterm2.rb
==> Name
iTerm2
==> Description
Terminal emulator as alternative to Apple's Terminal app
==> Artifacts
iTerm.app (App)
Error: undefined method `analytics?' for an instance of Homebrew::CLI::Args
/usr/local/Homebrew/Library/Homebrew/utils/analytics.rb:248:in `output_analytics'
/usr/local/Homebrew/Library/Homebrew/utils/analytics.rb:342:in `cask_output'
/usr/local/Homebrew/Library/Homebrew/cask/info.rb:39:in `info'
```
This showed a confusing message when the trash path was able to be
deleted using sudo since the untrashable array was updated but
the check was higher up for returning early.
```
==> Trashing files:
/Users/Shared/Maxon
/Users/Shared/Red Giant
~/Library/Application Support/Maxon
~/Library/Application Support/Red Giant
~/Library/Caches/net.maxon.app-manager
~/Library/Preferences/Maxon
~/Library/Preferences/net.maxon.app-manager.plist
~/Library/Saved Application State/net.maxon.app-manager.savedState
==> Using sudo to gain ownership of path '/Users/Shared/Maxon'
==> Using sudo to gain ownership of path '/Users/Shared/Red Giant'
Warning: The following files could not be trashed, please do so manually:
==> Removing all staged versions of Cask 'maxon'
```
The warning about files not getting trashed should only be shown if
some files didn't get trashed.
Fixes https://github.com/Homebrew/brew/issues/18901
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.
