Import these from the homebrew/formula-analytics tap and deprecate
that tap.
This required a little messing around with filenames and paths to get
it finding Python and writing to the user's home directory.
The logic has now been removed in previous commits. This just
removes some references to the `HOMEBREW_INTERNAL_JSON_V3`
environment variable along with reverting the changes to the
`Cachable` class that were originally added in
bd72ec812c3ed656dfcf8e24f77df142a1fe9cc1.
This is particularly useful for third-party Python formulae that have a ton of resources, not all of which may adhere to homebrew/core's strict policies. See #19240 for context.
I've also added logic that ignores `--ignore-errors` on `homebrew/core`, although I personally think this new behavior is also useful for mainline formula creation.
Before: error out on a single non-conforming resource, zero resource blocks added to formula, scary stacktrace.
After: all conforming resources added, all non-conforming resources identified in comments, error message at end, `brew` exits non-zero without scary stacktrace:-
```
% brew update-python-resources --ignore-errors gromgit/test/auto-coder || echo OOPS
==> Retrieving PyPI dependencies for "auto-coder==0.1.243"...
==> Retrieving PyPI dependencies for excluded ""...
==> Getting PyPI info for "aiohappyeyeballs==2.4.4"
[200+ resource lines elided]
==> Getting PyPI info for "zhipuai==2.1.5.20250106"
==> Updating resource blocks
Error: Unable to resolve some dependencies. Please check /opt/homebrew/Library/Taps/gromgit/homebrew-test/Formula/auto-coder.rb for RESOURCE-ERROR comments.
OOPS
% brew cat gromgit/test/auto-coder | ggrep -C10 RESOURCE-ERROR
license "Apache-2.0"
depends_on "python@3.11"
# Additional dependency
# resource "" do
# url ""
# sha256 ""
# end
# RESOURCE-ERROR: Unable to resolve "azure-cognitiveservices-speech==1.42.0" (no suitable source distribution on PyPI)
# RESOURCE-ERROR: Unable to resolve "ray==2.42.0" (no suitable source distribution on PyPI)
resource "aiohappyeyeballs" do
url "e4373e888f/aiohappyeyeballs-2.4.4.tar.gz"
sha256 "5fdd7d87889c63183afc18ce9271f9b0a7d32c2303e394468dd45d514a757745"
end
resource "aiohttp" do
url "952d49c730/aiohttp-3.11.12.tar.gz"
sha256 "7603ca26d75b1b86160ce1bbe2787a0b706e592af5b2504e12caa88a217767b0"
end
```
This is a direct copy of `trailofbits/homebrew-brew-verify`,
but in the `DevCmd` namespace instead.
Signed-off-by: William Woodruff <william@yossarian.net>
- use e.g. `$HOMEBREW_*` for cases where only the environment variable
is the entire backtick-quoted string
- use e.g. `${HOMEBREW_*}` for cases where the environment variable is
part of a backtick-quoted string to make clear what parts are variable
and what parts are not
- use `export HOMEBREW_*=...` for cases where we're talking about
setting the environment variable (because it likely needs to be
exported to work how they want)
Inspired by https://github.com/Homebrew/homebrew-bundle/pull/1579 making
similar changes for Homebrew/homebrew-bundle.
`brew tests --coverage` can fail to produce coverage information when
run on a small number of tests (e.g., `--only utils/curl`). We use
`ParallelTests::last_process?` in `tests/spec_helper.rb` to handle
the SimpleCov output but due to the way the method is implemented, it
doesn't work as expected if the number of processes is greater than
one but lower than the number of cores. I tried to address this
through changes to `spec_helper.rb` and/or changes to `ParallelTests`
but didn't meet with any success.
This works around the issue by disabling parallel test execution when
the `--coverage` option is used and the number of files to be tested
is lower than the number of CPU cores. I've been using this workaround
for months and it works as expected on my machine.
- Skip formulae that are autobumped by BrewTestBot,
to avoid useless effort spent by contributors who
are checking for formulae to bump and then we close
their PRs.
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".
`brew bump` will check for PRs related to a package even if livecheck
fails to identify new versions. This reworks related conditions to
ensure that related PR checks are only run when livecheck returns
version information.
