`Homebrew::SimulateSystem.current_os` may be returning the host OS or
a simulated OS and we can't be sure which in this context. At the
moment, this is expected to be the host OS but that may change in the
future. It shouldn't matter on a technical level but using "host" in
these variable names may lead to confusion.
This replaces "host" in names with "current", as it more accurately
describes the information.
This extracts the logic for generating the `system_options` array in
the `replace_version_and_checksum` method into a separate
`generate_system_options` method. This logic is becoming more complex
(after recent changes) and manually testing it is a pain, so this
change is intended to allow us to add tests. The tests added here
provide 100% coverage for the method.
This reworks the `SimulateSystem` args in the `bump-cask-pr`
`replace_version_and_checksum` method to respect `depends_on arch`
values in casks. That is to say, we shouldn't simulate Intel for a
cask using `depends_on arch: :arm64` and we shouldn't simulate ARM if
the cask uses `depends_on arch: :x86_64`.
In the process, this refactors how we collect/combine OS/arch values.
To make this approach work predictably, I removed the logic that
omits OS values matching the host OS (as `SimulateSystem` already
handles this). The `[{ os:, arch: }]` hash format only made sense when
we were omitting values, so this returns to the previous
`[[os, arch]]` array format (to align with the
`OnSystem::ALL_OS_ARCH_COMBINATIONS` array format).
This adds the ability to specify tests that depend on a certain CPU
architecture using `:needs_arm` or `:needs_intel`, similar to the
existing `:needs_macos` and `:needs_linux` metadata for tests that
depend on a certain OS.
The `replace_version_and_checksum` method handles a `CaskInvalidError`
when loading a cask (handling casks that aren't valid on Linux) but
we can sometimes still encounter an error when bumping a cask with
on_system blocks. For example, bumping `displaylink` will produce a
`Cask 'displaylink' is unreadable: undefined method 'csv' for nil`
error when `SimulateSystem` runs as Linux, as the cask interpolates
`version.csv.first` in a `license` string but `version` isn't set on
Linux.
This adds `Cask::CaskUnreadableError` to the `rescue` arguments,
which accounts for this particular situation (allowing `displaylink`
to be bumped like before).
`bump-cask-pr` was recently updated to add Linux support but the
change to the `replace_version_and_checksum` logic has broken the
command for casks that have on_system blocks that reference specific
macOS versions (e.g., `on_monterey :or_newer` in `logi-options+`).
The previous logic only simulated the arch, so the `current_os` value
on macOS was a specific version like `:sequoia`. The current logic
uses generic `:macos` values, which work for `on_macos` blocks but
don't work for blocks like `on_sequoia`, etc. This leads to an
`undefined method 'latest?' for nil` error, as `old_cask.version` is
`nil` in this scenario (i.e., none of the on_system blocks apply to
`:macos`, so `version` is never set).
This updates the method to only specify the OS in `system_options` if
the value doesn't align with the host (e.g., `:linux` on macOS),
which restores the previous behavior.
This also replaces `:macos` values with the newest macOS version
(e.g., `:sequoia`), so that `bump-cask-pr` on Linux can update casks
with on_system blocks that reference specific macOS versions. A
generic `:macos` value doesn't work with those on_system blocks, so
`version` is never called on Linux in that scenario but it works as
expected if we use the newest macOS value instead. This may not be
perfect but it brings `bump-cask-pr` a little closer to parity with
macOS on Linux.
Lastly, this skips `system_options` values where `old_cask` has no
version, as this means the cask doesn't apply to that OS/arch. We've
been seeing a related error on homebrew/cask autobump CI and this
guard should help to avoid it.
I do not like that `brew bump` command checks every single formula/cask,
even ones updated by BrewTestBot. Instead of showing useful info about
outdated packages, my terminal buffer is fludded with `Formula is
autobumped so will have bump PRs opened by BrewTestBot every ~3 hours`.
This flag excludes autobumped packages before checking them.
Signed-off-by: botantony <antonsm21@gmail.com>
- Remove check for `cask.depends_on.macos` as it seems to be always
present and set to at least >=10.11
- When we've specified multiple architectures, allow casks to be invalid
on some architectures.
The default behaviour is too strict for unofficial taps. We can still
warn elsewhere but, given the potential for false positives, let's
loosen things a bit.
It's both unexpected and undesirable for `brew bundle (exec|env|sh)` to
filter the environment and makes these tools less useful.
Not filtering the environment, though, causes issues with the
`brew bundle sh` shell. Fix this up and, while we're here, also improve
the formatting for both `zsh` and `bash` (the default) to use nicer and
more consistent prompts and colours.
To simplify this, consolidate some logic in a new
`Utils::Shell.shell_with_prompt` method and add tests for it and a
similar notice for `brew bundle sh`.
Finally, avoid printing out the notice when `HOMEBREW_NO_ENV_HINTS` is
set.
Fixes incorrectly marking bottles as relocatable, e.g.
425d4ea43d/Formula/p/pkgconf.rb (L34-L36)
This cannot be done for `/usr/local` as it is used outside Homebrew.
Other default prefixes are Homebrew-specific.
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
```
