Brew: Feature proposal: `brew cask upgrade --skip-first` to skip first package to be upgraded

[specious]

brew cask upgrade determines the list of casks which have newer versions available and then proceeds to install the latest version of each. In the not uncommon event that one of the packages fails to install due to some issue, it would be useful to be able to skip the first package in the list of remaining packages to upgrade. This would allow you to upgrade all the other packages without first having to solve the issue with the one that isn't installing.

There is a similar option in portage that allows you to emerge --resume --skipfirst in case one of the packages fails to install successfully.

I'm ready to open an PR and work towards properly implementing this feature with any advice from the maintainers and the community if the consensus is that this is a worthwhile idea. What do you think?

[specious]

/cc @amyspark @vitorgalvao @ilovezfs @MikeMcQuaid @commitay @reitermarkus

Who did I forget?

[commitay]

/cc ........

Please don't spam maintainers.

[ilovezfs]

Given Homebrew's autoupdate behavior, "first" may not mean the same thing as it meant in the last run.

[reitermarkus]

Yeah, --skip-first doesn‘t work well. Maybe --ignore-failed or something like that.

[ilovezfs]

In the case of unsatisfied requirements, that just became the default behavior for formulae on brew upgrade https://github.com/Homebrew/brew/pull/3644

@reitermarkus what would be the argument against making ignore-failed the default behavior?

[RandomDSdevel]

What would be more useful is the ability to say something like brew upgrade !("formula1 formulat2") and have brew upgrade everything but the formulas you've specified, particularly when you're holding off on a applying an upgrade until an issue with it is resolved and/or patched. (This would be even _more_ helpful for anybody who, like myself, builds from source almost exclusively, but I digress…) (Never mind, we're just talking about brew cask at the moment. It would be nice if Homebrew proper had this feature as well, though.)

[ilovezfs]

@RandomDSdevel that's brew pin

[RandomDSdevel]

@ilovezfs: Well, yes, you _could_ do it that way, but I'd personally save that for more long-term upgrade avoidance. Having a command-line option for brew upgrade that gives similar behavior to brew pin would be nice for situations when and where you only have to do it once, twice, or a small handful of times, after which some formula change makes it safe to upgrade again, particularly if you were _developing_ said change (you'd use the option with the version of the formula installed from its host tap's master branch, but _not_ when messing around with your local PR-staging branch for it; this would probably also involve a lot of brew switch, as well, though.)

[alyssais]

@RandomDSdevel

brew outdated | grep -v htop | xargs brew upgrade

[RandomDSdevel]

@alyssais: Ah, neat! That would certainly do the trick. (I take it you stuck htop in there as an example formula to omit due to the upstream mess surrounding that software's problems with causing users grief on High Sierra?)

[specious]

@alyssais:

brew outdated | grep -v htop | xargs brew upgrade

That is really not obvious, as brew outdated prints package names together with version numbers unless the output is redirected away from standard output, in which case it prints only the names. I don't think I would have easily guessed this approach. Thanks for the tip!

[specious]

So this means the brew cask equivalent is:

brew cask outdated | grep -v java | xargs brew cask upgrade

Which works wonderfully.

[RandomDSdevel]

I think this brew outdated | grep -v $FORMULA | xargs brew upgrade/brew cask outdated | grep -v $CASK | xargs brew cask upgrade trick should go in brew.sh's 'Tips and Tricks' page. Another one I've also found useful that might fit in well there is brew outdated | grep -v -f <(brew list --pinned) | xargs brew fetch (brew upgrade itself already ignores pinned formulae, of course.)

[ilovezfs]

We'd be happy to look at a PR for --ignore-failed but the UNIX-y approach seems fine for now.