Homebrew-cask: Proposal: Remove `auto_updates`.

[reitermarkus]

I have never seen the use for auto_updates. The concept of auto-updates just doesn't work well in combination with a package manager. I think the cons by far outweigh the pros for this.

The argument for auto_updates would be to save a few duplicated downloads. However, you actually have to regularly open/use the app in order for it to auto-update itself, which is probably only true for a handful of casks you have installed. This makes the argument moot.

Also, brew cask upgrade is confusing for users (https://github.com/Homebrew/homebrew-cask/issues/48181). I can understand why people are confused and think brew cask upgrade is not working.

I therefore propose removing auto_updates and assuming that when people are using brew cask, it is their first choice for updating applications. A divergence between the installed cask version and app version is definitely not a pro either.

[commitay]

I'm not really sure if I'd be in favour of this or not.

The argument for auto_updates would be to save a few duplicated downloads.

What would alternatives be for users that prefer the the current behaviour? Can we offer a better option than telling users to upgrade casks individually / scripting upgrade to exclude a particular cask or rm -rf /usr/local/Caskroom/{cask}?

[vitorgalvao]

Strongly against removal.

auto_updates doesn’t exist by itself but as a part of our commitment to having HBC perform its actions in a way that the result is as close as possible to the user having done them manually. This is an important mindset that solves a bunch disputes.

The concept of auto-updates just doesn't work well in combination with a package manager.

Back in the day, behaving like a traditional package manager almost killed HBC. We were stagnant for I don’t even recall how long because behaving in that way is incompatible with how macOS GUI apps expect to be handled. macOS GUI apps — with the exception of MAS apps — do not expect to be managed by a central authority and as such don’t behave in a way friendly to it.

Every time we tried to be smart (not requiring artifact stanzas, linking apps, …), those decisions came back to bite us. I’ll even argue our current cask model is suboptimal and *preflight stuff is a horrible hack. If installation procedures were a series of laid out steps, we wouldn’t need a bunch of other hacks we use (like container).

Moving to be dumber was what got the ball rolling again.

The argument for auto_updates would be to save a few duplicated downloads.

The argument is for us to not screw up current installs, which can happen in a few of ways. For example, apps in which you can change the update channel inside the app (Alfred, Intellij apps). We’d be constantly fighting with the user’s choice, downgrading them all the time.

By removing auto_updates we’re replacing bug reports of “upgrade doesn’t work”, which can be resolved with a link to documentation, with “upgrading is messing my install”, which is not easily fixable.

What we could do is keep auto_updates, remove --greedy, and add --non-greedy. This is where I’d point back to “HBC should do the same as if installed manually” and say the behaviour should stay as is. But I could be more easily convinced of the benefits of inverting current behaviour than removing auto_updates.

Finally, :latest casks are a problem either way, but ideally we should strive to get rid of them with the unrestricted appcast system.

[reitermarkus]

For example, apps in which you can change the update channel inside the app (Alfred, Intellij apps). We’d be constantly fighting with the user’s choice, downgrading them all the time.

I'd argue that if you choose to change the update channel inside the GUI you're playing with fire and you should not have used brew cask to install it in the first place.

What we could do is keep auto_updates, remove --greedy, and add --non-greedy.

Yes, I could live with brew cask upgrade defaulting to include auto-updating apps and still keeping auto_updates.

[commitay]

macOS GUI apps — with the exception of MAS apps — do not expect to be managed by a central authority and as such don’t behave in a way friendly to it.

This is where I’d point back to “HBC should do the same as if installed manually” and say the behaviour should stay as is.

Agreed. It is annoying explaining this to users as goes against their expectations but keeping the current behaviour with greedy as an opt-in for "power users" rather than opt-out for seems like the right choice.

Edit: implementing https://github.com/Homebrew/homebrew-cask/issues/41438 would probably help with some of the user confusion regarding upgrade.

[vitorgalvao]

I’ve been using Alfred for years (since version 1), and have always been on the most cutting-edge channel (pre-release and beta) without a single hiccup I can recall. I’m also a moderator on their forums and read every single new post. I’ve never found another user or developer with a serious issue pertaining to a pre-release. There’re real incentives to use pre-release channels, and that choice is all pros, no cons. There’s also no (officially) way to get the non-stable versions from outside the app.

For Intellij apps, we (HBC) tried keep up with the non-stable channels and we decided they were too much work to keep up to date, in large part because they’re always converging with stable channels, making updates non-trivial.

I'd argue that if you choose to change the update channel inside the GUI you're playing with fire and you should not have used brew cask to install it in the first place.

So in both cases this means punishing power users, which I’d argue are our core users. On the former case for no real reason, and on the latter for a decision we made previously (that if reversed would lead to more work for us again).

[reitermarkus]

There’re real incentives to use pre-release

I'm not arguing about pre-releases in a vacuum, I'm arguing about them together with brew cask.

What do you think about replacing auto_uodates with brew cask pin? Power users can install once and afterwards exclude it from further updates while regular users have the benefit of not needing to specify --greedy.

[commitay]

while regular users have the benefit of not needing to specify --greedy.

I don't see this as a benefit for regular users.

[vitorgalvao]

I'm not arguing about pre-releases in a vacuum, I'm arguing about them together with brew cask.

My point was that a lot of power users (our core users) use pre-releases and HBC. By telling them “for pre-releases do it manually”, we’re cutting out a huge chunk of HBC’s usefulness.

What do you think about replacing auto_uodates with brew cask pin?

brew cask pin sounds more confusing to me. It sounds like we’re going to prevent the application from upgrading either way (like HB does), not that we’re allowing it to upgrade itself.

[commitay]

We've had lots of issues about this from people _confused_ about the behaviour, we haven't had very many saying that the behaviour is _wrong_ and needs to be changed.

[reitermarkus]

We've had lots of issues about this from people _confused_ about the behaviour, we haven't had very many saying that the behaviour is _wrong_ and needs to be changed.

Being confused implies that the behaviour is wrong and not what they expected it to be.

[commitay]

Being confused implies that the behaviour is wrong and not what they expected it to be.

Because they expect it to behave like a traditional package manager, which it isn't.

[brianbrownton]

Could this just be resolved by adding output to the upgrade command indicating the casks they have installed which have auto_updates flagged and therefore will not be updated?

If we wanted to get more heavy-handed, we could even try launching the apps with auto_updates in an attempt to trigger their update functionality (or some other means, if they have a standalone update checker or service that runs).

[query]

The argument is for us to not screw up current installs, which can happen in a few of ways. For example, apps in which you can change the update channel _inside_ the app (Alfred, Intellij apps). We’d be constantly fighting with the user’s choice, downgrading them all the time.

I assume most app bundles have accurate version numbers? In that case, HBC can compare the version of the bundle on disk with the version that HBC installed. If they're not the same, warn the user that brew cask upgrade might downgrade the app, and skip the operation. This should cover @reitermarkus' case of infrequently-opened apps, with very little risk of unexpected downgrades.

In an ideal world, a mechanism to lexically compare version numbers would be even better, so that HBC would still upgrade in the case where brew cask install installed 2.0, auto-updates installed 2.1, and the latest cask is 2.2. I suspect, though, that trying to parse version schemes in a generic way is more trouble than it's worth.

[vitorgalvao]

I assume most app bundles have accurate version numbers? In that case, HBC can compare the version of the bundle on disk with the version that HBC installed.

I wouldn’t bet on that assumption. But even if that’s true, we don’t have accurate version numbers because we base them on the convenience of the number provided on the download URL, not the app itself.

Either way the comparison would not be trivial. For one it wouldn’t work for a whole bunch of casks that don’t use app, and we have a ton of those.

I suspect, though, that trying to parse version schemes in a generic way is more trouble than it's worth.

It is, and we’ve already made the conscious decision to not do it.

[query]

I wouldn’t bet on that assumption. But even if that’s true, _we_ don’t have accurate version numbers because we base them on the convenience of the number provided on the download URL, not the app itself.

Either way the comparison would not be trivial. For one it wouldn’t work for a whole bunch of casks that don’t use app, and we have a ton of those.

The actual version number doesn't need to be part of the cask.rb file. It can just be recorded at install time, from Info.plist for an app or pkgutil --pkg-info for an installer bundle.

There are also a couple of other mechanisms even if we don't trust version numbers, like checksums of app bundles or the install-time for installers, which pkgutil keeps track of.

[vitorgalvao]

@query All those solutions fall into the “more trouble than it’s worth” category. They also try to be way too smart, and I’m betting we’d be bitten by the edge cases.

[query]

I don't understand what "smart" means here. I agree that trying to come up with an ordering of arbitrary version numbers is too clever for its own good, but just keeping a record of what HBC installed and comparing it to what's on disk is a pretty straightforward way to determine if the user has been updating outside of HBC. We can avoid accidental downgrades, while allowing people who prefer to manage upgrades inside HBC to continue to do so.

At the very least, brew cask upgrade should warn about packages with auto_updates, as @brianmorton suggested. The previously filed issues show that people already assume brew cask upgrade does something similar to brew upgrade, and get confused when it doesn't.

[vitorgalvao]

I don't understand what "smart" means here.

It means trying to guess instead of being explicit. We tried guesswork in the past and it failed miserably. There are too many exceptions for every case.

Clearly upgrade needs to be better at communicating, I agree with that.

[vitorgalvao]

upgrade is now better at communicating, displaying a “Casks with auto_updates or version :latest will not be upgraded” message.

Closing this, unless someone still has any points against it.