Pass `path.to_s` instead of `path` (a Pathname) to
`LinkageCacheStore.new`, matching the pattern used in
`linkage_checker.rb`. The sig on `initialize` correctly requires a
String since the value is used as a JSON-serializable database key.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The `CacheStore` base class used `*args` with `raise NotImplementedError`
as a pseudo-abstract pattern. When subclasses add Sorbet `sig`
annotations, the Sorbet runtime's override shape validation rejects the
incompatible signatures (child methods have fixed params, parent has
`*args`).
Replace this pattern with Sorbet's proper `abstract!` declaration and
remove the pseudo-abstract methods entirely. `CacheStore` is never
instantiated directly - all callers use concrete subclasses.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add Sorbet `sig` annotations to all methods and `T.let` for instance
variables to enable `typed: strict` in `linkage_cache_store.rb`.
Contributes to #17297
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When running `brew uninstall A B C` where one item is unavailable,
the entire command halted before uninstalling anything. Now errors
for unavailable items are collected and reported at the end while
valid items are still uninstalled.
- Use `to_formulae_and_casks_and_unavailable` for name resolution so
unavailable items are captured as values instead of raising
- Add `NoSuchKegError` to the rescue clause in
`to_formulae_and_casks_and_unavailable`
- Collect per-cask exceptions in `Cask::Uninstall.uninstall_casks`
following the pattern from `Cask::Upgrade.upgrade_casks!`
- Apply same per-cask error collection to the zap loop
- Report unavailable errors via `ofail` after all uninstall work
completes
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Extend the same pattern from the previous commit to `uninstall` and
the new-cask install path in `install`.
In `uninstall`, both `Cask::Uninstall.uninstall_casks` and
`Cask::Installer#zap` can raise, which would skip
`Cleanup.autoremove`.
In `install`, the `new_casks.each` loop calling
`Cask::Installer#install` can raise, which would skip formula
installations, `Cleanup.periodic_clean!`, and message display.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When `Cask::Upgrade.upgrade_casks!` or `Cask::Reinstall.reinstall_casks`
raises, the exception now gets caught with `ofail` (which sets
`Homebrew.failed = true`) instead of propagating up and skipping
cleanup, pkgconf reinstall, and message display.
This matches how formula upgrades already handle `BuildError`.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
We use "current" terminology in livecheck to refer to the current
version(s) that a formula/cask uses and I think this is easy to
understand. This renames the `old_versions` variable to
`current_versions`, which better reflects the intention and aligns
with other related variable names throughout `bump`.
This refactors the `newer_than_upstream` logic to make it a little
more flexible, using a programmatic approach to create the version
comparison pairs rather than hardcoded arch values. This also extracts
the logic for defining `multiple_versions` and `newer_than_upstream`
into a separate `compare_versions` method. Besides simplifying
`retrieve_versions_by_arch`, this allowed me to add a reasonable test
for this code.
It's worth noting that this compares the current version to the
highest new version when the current version does not differ by arch
but the new version does. There isn't one clear way to handle this
(e.g., you could treat the current version as newer than upstream if
it's higher than any new version) but this felt like the least
confusing behavior. I'm also working on modifying `bump` to handle
single-arch version bumps, so comparing to the highest new version
also makes more sense in that context (i.e., if the current version is
treated as newer when it's higher than any new version, a lower new
version for Intel could prevent `bump` from updating to a higher new
version for ARM).
For what it's worth, this removes the `|| newer_than_upstream[:arm]`
fallback for when `multiple_versions[:current]` isn't true in
`retrieve_and_display_info_and_open_pr`, as the `:general` value
should be present in that situation (based on how this is handled
here).
The `newer_than_upstream` booleans can be incorrect when there's one
current version but multiple new versions or vice versa. This occurs
because the related comparisons are strictly done between the same
`BumpVersionParser` values and it doesn't work as expected in this
scenario (i.e., the `:arm`/`:intel` values are `nil` when `:general`
is used for the version and vice versa).
This adds additional logic to define which comparisons are used
depending on whether the current and/or new versions have multiple
versions, notably comparing against the `:general` version when
there's a difference between current and new. One caveat is that
`bump` will fall back to the `newer_than_upstream[:arm]` value when
the current version uses one version and `:general` isn't present
(as is the case when `multiple_versions[:new]` is true) but this
aligns with other usage of ARM as the favored arch in `bump` and
`bump-cask-pr`. This isn't the most elegant solution overall but it
works as expected (I wasn't able to achieve the same result through
more modest modifications, not to say that it's not possible).
The `multiple_versions` boolean is true if the current or new versions
are split based on arch but this can cause unexpected behavior when
`multiple_versions` is used as a conditional. In some places we need
to check whether there are multiple current versions and in other
places we need to check if there are multiple new versions, so the
existing value isn't granular enough. This may not be a problem when
both current and new have the same version setup but it can cause
issues when there's a difference.
This changes `multiple_versions` to a hash with boolean values and
updates related conditions to use the contextually-appropriate value.
This resolves a couple of issues:
* The current version for multi-arch casks with one `version` were
being split into arm/intel values in the output when the new versions
differ based on arch and vice versa. These changes ensure that the
current and new versions are only split in the output when the version
differs.
* The `deprecated[:general]` value wasn't being set properly when the
current and new versions didn't have the same version setup, as the
fallback value specifically needs to be set when there aren't multiple
current versions.
Besides that, we also need to specifically check if there are multiple
current versions to be able to correctly identify current versions
that are newer than the upstream version when both current and new
don't have the same version setup but this will be addressed in
another commit.
We already create variables for `version_info` values that are reused
throughout bump's `retrieve_and_display_info_and_open_pr` method, so
this adds additional variables for `multiple_versions` and
`newer_than_upstream` to tidy up related usage.
`brew bump` adds a " (deprecated)" annotation after the current
version text if the formula/cask is deprecated and this works when
printing one version but it's confusing when arch-specific versions
are printed because it can incorrectly suggest that only the Intel
version is deprecated even if both ARM and Intel share the same
top-level deprecation. For example, a cask with an implicit
deprecation from a `disable!` call with a future date appears like
this:
```
Current cask version: arm: 1.2.3
intel: 1.2.3 (deprecated)
```
This addresses the issue by modifying how the deprecated annotation
is added after version text, so that it will correctly appear after
the arch-specific version(s) it applies to. Additionally,
`formula_or_cask.deprecated?` depends on the execution environment, so
this captures the value in `retrieve_versions_by_arch` when the arch
is simulated. This setup ensures that `bump` is able to correctly
handle packages where one arch is deprecated but another isn't.
`brew bump` uses one `general` version in the `BumpVersionParser`
object when the ARM and Intel versions are identical. However, only
the `arm` and `intel` values are used when printing the current
versions for each arch, so bump won't successfully print the current
versions for casks that have one `version` but different assets for
each arch:
```
Current cask version: arm:
intel: (deprecated)
```
This addresses the issue by modifying the related output strings to
fall back to `current_version.general` if the `arm` and `intel` values
are blank.
Shaan Majid