initial attempt for an automatic cask update

[doits]

This is a quick attempt to update outdated casks. I use this approach in a custom script (working for 1+ year) and implemented it here now.

If this is something you want to include I can write some specs for it, too, but first I am open for comments if you even want something like this.

[MikeMcQuaid]

If this is something you want to include I can write some specs for it, too, but first I am open for comments if you even want something like this.

Yep, we always need specs for 100% code coverage. Additionally, we'd need e.g. brew bundle check to also make use of this. Before I get you to do more code let's talk about this, though.

this is a quick attempt to update outdated casks. I use this approach in a custom script (working for 1+ year) and implemented it here now.

I've personally never found this to be a problem as-is because the majority of casks do not require a manual upgrade but upgrade automatically with Sparkle. Are there some in particular that need this? If so, perhaps this would be better as an optional feature than could be enabled on specific casks in the Brewfile?

[doits]

If this is something you want to include I can write some specs for it, too, but first I am open for comments if you even want something like this.

Yep, we always need specs for 100% code coverage. Additionally, we'd need e.g. brew bundle check to also make use of this. Before I get you to do more code let's talk about this, though.

Ah sorry, I wanted to say I'm not sure if you even want to have a cask update mechanism implemented. For the specs: sure, they are mandatory!

I've personally never found this to be a problem as-is because the majority of casks do not require a manual upgrade but upgrade automatically with Sparkle. Are there some in particular that need this?

I have the special use case that I manage multiple workstations with homebrew. Apps are installed without write rights for those users (because the could add malicious code that would be run by others for example). So there is an admin user that updates those casks for everybody. If this is not done by an script automatically, he would need to open each one to let it self update (which if of course not manageable).

Not sure what Sparkle is, though, maybe this would help me?

If so, perhaps this would be better as an optional feature than could be enabled on specific casks in the Brewfile?

Yep, OK for me (so this would be optional then).

[doits]

I just hooked it up to brew bundle check and refactored a little bit. I'm open for comments how to implement it in an optional manner and/or how you'd want it to be refactored/implemented.

(New specs will have to be added and existing updated then, too)

[MikeMcQuaid]

Ah sorry, I wanted to say I'm not sure if you even want to have a cask update mechanism implemented.

My main concern is that this method isn't support by brew cask to detect if updates have happened and may stop working in the future. CC @vitorgalvao and @jawshooah for thoughts on this.

I have the special use case that I manage multiple workstations with homebrew. Apps are installed without write rights for those users (because the could add malicious code that would be run by others for example). So there is an admin user that updates those casks for everybody. If this is not done by an script automatically, he would need to open each one to let it self update (which if of course not manageable).

Ok, I see.

Not sure what Sparkle is, though, maybe this would help me?

Sparkle is what most Mac .apps use to autoupdate when you run them. The problem with your method is you're bypassing Sparkle and relying on Cask to update their URLs. I know for a fact that these aren't updated nearly as often (and sometimes not at all) for Sparkle applications because they autoupdate.

[MikeMcQuaid]

CC @xu-cheng for thoughts on this PR.

[xu-cheng]

I would prefer to waiting cask supporting official API to list outdated cask instead of hacking.

Also since cask have mixed apps where some support autoupdate, some do not. I'm not sure current approach is what more general usercase would want.

[doits]

I would prefer to waiting cask supporting official API to list outdated cask instead of hacking.

I'm waiting for this for 1+ year :-). Doesn't make the hacky solution better, but at least it works right now ... I think when official support comes out, the required change would be small to adopt to it. I'd be willing to maintain the support for it.

Also since cask have mixed apps where some support autoupdate, some do not.

IIRC at least the tendency for a cask is to have versioned urls and update those when a new version is released where this is possible (sometimes the urls are note versioned for some casks because there is not versioned url available by the app developer).

So yes, it is not a 100 % solution because those casks with a latest url will not be able to be auto updated. (Could be implemented behind a flag, too, to force update latest casks, but that's the next story)

I'm not sure current approach is what more general usercase would want.

Yeah, I can understand this, too. So I am totally OK to make this optional or hide it behind a flag - or not implement it at all.

I also understand that most users simply have their own one user macs, so this is really not beneficial for them (because of the auto update thingy).

So I have a mixed feeling about this, too, and are open to what you say. I'll use this in my network to see how this works out (and maybe refine it). (At least better than my custom ruby script ;-))

[MikeMcQuaid]

I'm waiting for this for 1+ year :-). Doesn't make the hacky solution better, but at least it works right now ... I think when official support comes out, the required change would be small to adopt to it. I'd be willing to maintain the support for it.

The problem is: there may not be official support and this hack could be broken meaning this feature no longer works.

So yes, it is not a 100 % solution because those casks with a latest url will not be able to be auto updated. (Could be implemented behind a flag, too, to force update latest casks, but that's the next story)

Yeah, I can understand this, too. So I am totally OK to make this optional or hide it behind a flag - or not implement it at all.

I also understand that most users simply have their own one user macs, so this is really not beneficial for them (because of the auto update thingy).

Given all these: I think we'll pass on this for now although it may be worth trying to get code accepted into Cask itself to make your process easier. Thanks for your PR and for understanding; hope we can accept another one in future!

[vitorgalvao]

My main concern is that this method isn't support by brew cask to detect if updates have happened and may stop working in the future.

The official answer is that we don’t currently support upgrade, and any user method to fake it is unsupported and use-at-your-own-risk, especially since most methods rely on brew cask list which we know is terribly broken at the moment.

upgrade is the most requested feature by far, but we have so many things that need to be fixed first, we haven’t even gotten to the discussion on how to go about it. What we do know is that when it is working, upgrade will not upgrade casks that use auto_updates true, so it may not even cover your case. See this issue for a detailed explanation.

[doits]

What we do know is that when it is working, upgrade will not upgrade casks that use auto_updates true, so it may not even cover your case.

That would really be a pity for me, but we should wait until this is really implemented before discussing it (things may change until then).

Maybe I am too into the idea that homebrew (cask) is a traditional package manager (like the apt, yum, ..., in linux world) - it looks like it does not want to be such and I shouldn't try to use it as such.

[vitorgalvao]

things may change until then

Extremely unlikely. Really do not count on it.

Maybe I am too into the idea that homebrew (cask) is a traditional package manager (like the apt, yum, ..., in linux world) - it looks like it does not want to be such and I shouldn't try to use it as such.

Precisely. The above linked issue explains why. It simply does not work. GUI apps do not want to be managed, and it breaks too many things. Our goal now is to be as close as possible to a manual installation (but more convenient).

However, I do envision a solution to your problem. Perhaps when we have an outdated command, we can have an option there to show all outdated casks, even the ones using auto_updates true. That way, even if upgrade does not upgrade those, you will still get a comprehensive list you can install --force with.