livecheck: Add ExtractPlist skip to SkipConditions

[samford]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

When the --extract-plist option was added to livecheck (#16759), 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.

Outside of the organizational improvement, this also fixes a related issue with the livecheck --json output when an ExtractPlist cask is included in a multi-cask run without the --extract-plist option. In this scenario, we wrongly get non-JSON output alongside the expected JSON data:

$ brew livecheck -j 0-ad 1clipboard actual-odbc-pack
==> Running checks
1clipboard: skipped - Livecheck skipped due to the ExtractPlist strategy..] 1/3
[
  {
    "cask": "0-ad",
    "version": {
      "current": "0.0.26-alpha",
      "latest": "0.0.26-alpha",
      "outdated": false,
      "newer_than_upstream": false
    }
  }
]

With this change, we receive the expected JSON output:

$ brew livecheck -j 0-ad 1clipboard actual-odbc-pack
[
  {
    "cask": "0-ad",
    "version": {
      "current": "0.0.26-alpha",
      "latest": "0.0.26-alpha",
      "outdated": false,
      "newer_than_upstream": false
    }
  },
  {
    "cask": "1clipboard",
    "status": "skipped",
    "messages": [
      "Use `--extract-plist` to enable checking multiple casks with ExtractPlist strategy"
    ],
    "meta": {
      "livecheckable": true
    }
  },
  {
    "cask": "actual-odbc-pack",
    "status": "skipped",
    "messages": [
      "Use `--extract-plist` to enable checking multiple casks with ExtractPlist strategy"
    ],
    "meta": {
      "livecheckable": true
    }
  }
]

---

Besides that, this updates the language around the --extract-plist flag (usage description, code comments) to clarify the behavior. From the description, it would seem that the ExtractPlist strategy is only enabled when --extract-plist is used. Instead, livecheck automatically enables the strategy if the command is run on only one cask.

[apainintheneck]

The --extract-plist option is only available for brew livecheck however adding this to SkipConditions will mean that this new skip condition will now affect brew audit and brew bump as well. Is that intentional?

I'm specifically looking at the changes to SkipConditions.referenced_skip_information which is used in those three commands.

[samford]

The --extract-plist option is only available for brew livecheck however adding this to SkipConditions will mean that this new skip condition will now affect brew audit and brew bump as well. Is that intentional?

It wasn't intentional and I had simply forgotten that bump and cask audits also use SkipConditions, so thanks for the catch. I'll take a look at it tomorrow but, off the top of my head, if we want to maintain the existing behavior (not restricting ExtractPlist), it could be as simple as adding extract_plist: true to the related calls in those areas. Alternatively, we could have extract_plist default to true and specifically pass a false value in Livecheck#run_checks to trigger the skip.

[apainintheneck]

Either of those options makes sense to me.

[samford]

I updated the #skip_information and #referenced_skip_information methods to use true as the default extract_plist value, which will take care of the aforementioned issue. With this setup, we don't have to update the bump and audit calls (or any future calls outside of livecheck), which maybe seems a little better than the other option (adding an explicit extract_plist: true to those calls).

[MikeMcQuaid]

Thanks @samford!