livecheck: clarify livecheckable language

[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?

---

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".

[samford]

homebrew-test-bot/lib/tests/formulae.rb contains return unless formula.livecheckable?, so [if we go forward with this] we will probably have to:

• Comment out the odeprecated calls in the #livecheckable? methods (edit: done)
• Merge this
• Update test-bot to use #livecheck_block?
• Create a follow-up PR to uncomment the odeprecated calls

[samford]

As discussed, the latest push updates this to use livecheck_defined? as the replacement method name (in place of #livecheckable?) and renames has_livecheck_block to livecheck_defined.

I've commented out the odeprecated calls for the moment, so we can merge this and replace #livecheckable? usage in homebrew-test-bot (Homebrew/homebrew-test-bot#1316). Once that's done, I can create a follow-up PR to enable the odeprecated calls.

Since we don't have a way of gracefully deprecating fields in the JSON output (see the discussion above), this simply removes the obj[:meta][:livecheckable] field from the JSON output in favor of obj[:meta][:livecheck_defined]. If possible, we may want to add a note to the description of the next GitHub release to make this clear (and to describe the fix). Maybe something like:

The #livecheckable? method for formulae/casks/resources (indicating whether a livecheck block is present) has been renamed to #livecheck_defined?. #livecheckable? has been deprecated and will be removed in the future.

Similarly, the ["meta"]["livecheckable"] field in brew livecheck --json --verbose output has been removed and replaced with a ["meta"]["livecheck_defined"] field. These both serve the same purpose, so this is only a name change.

[MikeMcQuaid]

Thanks @samford!

Unless this was a public API: don't think it needs a odeprecated.

If it is a public API: it probably should not have been 😄