brew: Don't abort entire brew cask upgrade if one cask fails

Right now, if you run brew cask upgrade and one of your casks fails (e.g., the depends_on macos stanza), two things happen:

  1. You get the correct message (e.g. Error: Cask cask_name depends on macOS release..., Error: Checksum for Cask 'superduper' does not match, Error: Download failed on Cask cask_name..., etc.)
  2. brew cask upgrade stops

brew cask thus won’t ever upgrade any casks coming alphabetically after the failing cask. While most issues should be fixable, if there is a macOS dependency issue, there’s nothing to “fix” outside of updating to the latest macOS: a cask depending on mojave will obstruct high_sierra users, despite homebrew-cask officially supporting the two latest macOS point releases.

One workaround is to manually parse out each cask by piping brew cask outdated through grep -v and then into brew cask upgrade; this should work but is repetitive and obviously not ideal or easily scalable. Another is to remove the relevant files from the caskroom and stop using brew-cask for the application(s) in question; likewise, this isn’t ideal.

Expected behavior would be for installer to raise the error as appropriate but for upgrade to rescue and continue with any remaining casks. This would match what brew does after #3644 and I believe is essentially what @ilovezfs suggested should be the default behavior in https://github.com/Homebrew/brew/issues/3634#issuecomment-356304225.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 6
  • Comments: 16 (6 by maintainers)

Commits related to this issue

Most upvoted comments

I did a bit of digging, but don’t have time right now to finish a fix. Adding code pointers to any others who are open to picking this up.

General thoughts:

  • IMO best option would be to collect various errors rather than immediately throwing them up to the caller. This will allow the cask upgrade to finish, and the notify the user of any problems.
  • Caveats to the above are where casks depend on each other and the dependency is broken, since then it would be ideal to intelligently abort the attempted upgrade only for the child casks.

Hope this helps other fellow hackers.

Stale bot, keep this open!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

Wasn’t this fixed by #5983 ?