brew cask upgrade outline

[vitorgalvao]

This issue is meant to outline the desired behaviour of upgrade (and outdated). Marking as ready to implement but discussion is encouraged. Will keep this top post updated with the final decisions of the discussion.

outdated should be implemented first, to make sure we have a solid foundation. upgrade should be built on top of it

Behaviour of brew cask outdated:

1. If given arguments, act on those casks. If not, act on all installed casks.
2. If called with --greedy, jump directly to step 5.
3. Ignore the ones that have auto_updates true.
4. Ignore the ones that have version :latest.
5. For the rest, compare the installed version to the latest one.
6. Output outdated casks with the same format as Homebrew:

aria2 (1.30.0) < 1.31.0
cmake (3.7.1) < 3.7.2

Behaviour for brew cask upgrade:

Same steps 1–5.

6. For the ones that differ, run the uninstall and install steps. Uninstalling is necessary to avoid leaving old traces of it when uninstallation procedures change.
7. If install fails (after uninstall), revert to previous version.

---

For those interested in giving a go at this, take a look at Homebrew/brew#1523. It should give you a starting point (but don’t feel obligated to use it). That specific PR has things that would need to be removed (pin/unpin) and added (take auto_updates into account). If working on it, ideally you could commit to provide some further support for the feature for a little while (just enough to make sure the code itself is stable, not be tied to it ad eternum).

There was an important consideration when thinking about this feature:

You have a commercial app at version 3.2. The developer releases a paid upgrade: 4.0, the cask is updated, and you upgrade. However, you did not want to pay for version 4.0. Now you’re stuck with a version you do not want. Not only is that a bad experience for you as a user, now you’ll likely introduce that last version into caskroom/versions, further filling the repo.

Some solutions were discussed, but ultimately it was argued they might not be needed or be detrimental at this stage, before we have a better understanding on how best to proceed:

(…) we have auto_updates (not yet taken into account in this PR) and I’m thinking: “are there any commercial apps that do not auto-update”? I’m betting those might very well be the minority if they exist (after all, if you ask for more money for upgrades, you want to auto-update so your users get notified).

---

Pinging @caskroom/maintainers. Any user is welcome to chime in.

[miccal]

This looks promising - may I suggest, though, that as a first step in this and to provide some testing, that brew cask outdated gets done and pushed before brew cask upgrade.

The reason I suggest this is that it seems to me the proposal for brew cask outdated doesn't actually do anything but list outdated Casks. Implementing this first will not interfere with user's existing Cask installs, and may then highlight any potential problems that we can tackle before implementing brew cask upgrade.

[vitorgalvao]

@miccal No objections. Ideally they’ll be built at the same time anyway, and upgrade should lean on outdated.

[reitermarkus]

This looks promising - may I suggest, though, that as a first step in this and to provide some testing, that brew cask outdated gets done and pushed before brew cask upgrade.

I second that, as we first need to figure out what outdated means exactly.

[vitorgalvao]

Edited top post to give precedence to outdated. Also added another step: “ignore the ones that have version :latest”.

[mwean]

I think this is still needed. I've had several issues with the Slack app where the auto-update showed no updates, but there was an updated cask. I'm pretty busy, but I might be able to look into this next weekend.

[reitermarkus]

You should still be able to force updates for :latest casks, at least.

[miccal]

I think this is still needed. I've had several issues with the Slack app where the auto-update showed no updates, but there was an updated cask. I'm pretty busy, but I might be able to look into this next weekend.

I have a similar issue with Dropbox, so I run cd /usr/local/Caskroom/; rm -r dropbox; cd so that Dropbox does not appear on brew cask list and therefore will not be updated whenever the Cask is updated.

I have always had issues whenever I force Dropbox to update.

[vitorgalvao]

so I run cd /usr/local/Caskroom/; rm -r dropbox; cd

Small note: cd - changes to the previous working directory. So cd /usr/local/Caskroom/; rm -r dropbox; cd - will get you back to wherever you were before. But why not just rm -r /usr/local/Caskroom/dropbox directly?

Even in those cases cases of Dropbox and Slack, presumably they’d still be auto-updated at some point and it might be that the apps are themselves delaying it on purpose (to prevent everyone contacting the server at once?). With that in mind, I don’t think we need to by default force those to update when the cask does. We might still ignore it. If a user knows an update was released and wants it right now, reinstall suffices.

[miccal]

Small note: cd - changes to the previous working directory. So cd /usr/local/Caskroom/; rm -r dropbox; cd - will get you back to wherever you were before. But why not just rm -r /usr/local/Caskroom/dropbox directly?

I like to be in the directory I am working in - don't ask me why, because I don't have an answer!

[leipert]

I am using buo/homebrew-cask-upgrade successfully for over 6 months.

For me it seems like brew cu --dry-run behaves like the wanted brew cask outdated, with the exceptions

1. you just can check all casks
2. auto_updates casks are not filtered out
3. the output format is different from brew

brew cu behaves like the wanted brew cask upgrade, except it does not do rollback or the uninstall routines.

I just wanted to link to this project, as it is already written in ruby and maybe some of the code/ideas can be reused.

/cc buo/homebrew-cask-upgrade#23

[vitorgalvao]

@leipert As has been repeated ad nauseam and is even stated in that repo, those scripts are fragile and rely on unreliable features. By your own admission, that one is missing pretty major stuff.

Lets please focus on building this right and natively, not retrofitting incomplete scripts that use user-facing features. Those are slow and can’t be trusted entirely.

[claui]

While I fully agree with what @vitorgalvao said, thank you @leipert for the heads up 👍

[colindunn]

Would love to see a flag for both outdated and upgrade to show auto_updates casks anyway. Just in case there was an error in the cask, or you have the auto update feature in the app disabled for some reason.

[vitorgalvao]

or you have the auto update feature in the app disabled for some reason

How?

[toonetown]

I agree. It would be nice to be able to force the update and outdated checks… For example, most apps that do auto update, have the option to opt in to automatic updates. Someone may turn that off in the app, and rely instead on hbc to do the updates. I don't know why I would want to do that… But it might be a use case to consider.

[vitorgalvao]

With multiple maintainers and users asking for it, --force has now been added to the top post.

[vitorgalvao]

Changed --force to --extensive (seems more accurate/clearer).

[mwean]

What does --extensive mean? --force makes more sense to me

[toonetown]

I think within the context of "outdated" "--extensive" makes more sense (i.e. brew cask outdated --extensive) - but within the context of "upgrade", "--force" makes more sense (i.e. brew cask upgrade --force).

However, it gets confusing when there are two different options with basically do the same thing.

Personally, I prefer "--force" (even brew cask outdated --force makes a little bit of sense)...but I really don't care what the option is called.

[toonetown]

And a minor nitpick - for "Behavior for brew cask upgrade", it states "Same steps 1–5." and then it starts with step "5" again.

[mwean]

What about --all?

[vitorgalvao]

And a minor nitpick - for "Behavior for brew cask upgrade", it states "Same steps 1–5." and then it starts with step "5" again.

Thank you. Fixed.

but within the context of "upgrade", "--force" makes more sense (i.e. brew cask upgrade --force).

I feel --force is inadequate because it looks like we’re doing a force reinstall, and that is not the case at all. I’d rather we save the keyword for if we actually need it later.

What about --all?

I fear that sends the wrong message. Just as people ran brew update && brew cask update (which we deprecated it exactly because it was being used wrongly), --all is “what do you mean “all”? Of course I want all to be updated, that should be the default”. I’m betting we’d see that option used in a majority of the time when it doesn’t make sense.

--extensive to me means “do more than the recommended”. Whatever the exact word is, that’s the message I think it should convey: “you should not be using this flag most of the time, and it does more than the recommended”. It also indicates the operation will take longer (which it will).

I think it’s more beneficial to have a word users aren’t absolutely clear about and as such will need to read the docs, than one they think they are clear about when it actually means something else.

[leipert]

Regarding those two statements:

or you have the auto update feature in the app disabled for some reason

How?

I don't know why I would want to do that… But it might be a use case to consider.

I actually disable all autoupdates by blocking http(s) calls with Little Snitch for most apps and/or disabling the auto checks in the options, because I do not want them to send more information "home" than necessary and do not want to handle constant nagging/auto-downloads. I'd rather have manual updates with the help of brew cask, so I have control over when an updates happen and which apps will get updates.

This brings me to my question:

Would it make sense to have two different flags for auto_updates true and version :latest?
Because on a normal day I just want nicely versioned upgrades for e.g. firefox and not for version: latest casks.

Sorry for hijacking the discussion again and a big 👍 for all your work, you lovely maintainers :)

[vitorgalvao]

@leipert That setup makes you an outlier.

Just like changing the install directory to /Applications HBC is a slight inconvenience to users who run on non-admin accounts, or how HB does not support installing anywhere other than /usr/local, even though that is technically possible, #13201 is clear: workarounds in the code make a mess, and our procedure should seek to emulate normal manual usage.

Blocking all auto-upgrades and upgrading manually is not common enough to be supported as a specific use-case and complicating the options.

We might eventually reach the conclusion it is indeed worth it, but at this point I don’t see it.

[leipert]

@vitorgalvao
I know it makes me an outlier and I demand no support for my setup. Just shared it, so you maintainers have a better understanding how HBC is used "in the wild".

[claui]

Good suggestions so far! While --force seems obvious at a glance, I don’t see how we can make it work well in practice, given the commitment we already have made in too many places that whenever we say --force, we mean “do whatever it takes to make this work” and that is a whole different thing.

With upgrade --all, we would give users too many ways to read either less or more into it than it actually is (cf. @vitorgalvao’s example).

Regarding --extensive: of the suggestions on the table so far, I can see it work best; yet, it feels just a tad too smart, overly far removed from our everyday language. (Let’s say your spouse just returned from work. Would you, in real life, greet him/her with the words, “Howdy love! Would you mind taking off your shoes because I just gave the house an extensive vacuuming?”)

Let’s consider simple words, like --greedy. I’d personally prefer --greedy; it feels more in touch with the language we actually use in our lives. It’s quite vivid so users might have an easier time to memorize it; that gives it a practical value. It’s already being used in the wild as a configuration option (although this is true for the other suggestions, too). Programmers will probably recall greedy from yet another, not too unfamiliar domain; and while we’re there, one of its antonyms happens to be surprisingly consistent with what we already have in mind for the default, non--greedy behavior: “try to do as little work as possible.”

[RandomDSdevel]

You're very welcome, @monouser7dig. It's always a pleasure to help others find what they're looking for. Now, back to my regularly scheduled lurking…

[toonetown]

I've got a question about brew cask outdated and --greedy...I'd like to list all the non-latest versions...but it seems to be unable to pipe the results out. For example, if I run:

> brew cask outdated --greedy
app1 (latest) != latest
app2 (latest) != latest
app3 (1.2.3) != 1.2.4
app4 (latest) != latest

All is good so far, but I get this:

> brew cask outdated --greedy | grep -v '(latest)'
app1
app2
app3
app4

And even:

> brew cask outdated --greedy 2>&1 | grep -v '(latest)'
app1
app2
app3
app4

Is there a way to specify that I want that version information to be piped to my grep command instead of dropped?

[joshka]

--verbose will do it.

[colindunn]

Just wanted to add this one here too in case it's relevant. virtualbox was updated today with a minor version change which happens to be a dependent of virtualbox-extension-pack. Reinstall works fine, but then the extension pack is missing because everything had been deleted even though cask shows the package as installed.

Should there be a method of removing dependents and then adding them back again as part of updating casks?

EDIT: Hmm, the pack might have been there after all. Still an interesting question.

[daylightbrightledlight]

@claui I like your explanations regarding the --greedy flag, but I'm in favor of the --extensive flag that @vitorgalvao used. Is it okay to settle with both flags?

[vitorgalvao]

@daylightbrightledlight That train as already left. --greedy has been decided and is already implemented in outdated.

Having two wildly different flags that mean the same thing is a recipe for confusion, so we won’t add --extensive.

[daylightbrightledlight]

@vitorgalvao Okay. I understand. Thanks for the support.

[joh-klein]

Is there a reason, why outdated is not documented yet? Especially the --greedy and --verbose flags …

[vitorgalvao]

Is there a reason, why outdated is not documented yet? Especially the --greedy and --verbose flags …

man brew-cask | less +'/outdated '

[daylightbrightledlight]

How is the progress?

[vitorgalvao]

@daylightbrightledlight No comments generally mean no progress. outdated is done; upgrade is not. As usual, PRs welcome.

[danielbayley]

FYI: Just pointing out homebrew-cask-upgrade in case it might be relevant here.

[vitorgalvao]

@danielbayley #29301 (comment)

[vitorgalvao]

Almost there: Homebrew/brew#3396