-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Application Auto-Update Interfacing and Automation? #14833
Comments
To be honest, I see no value in this. Very few apps have CLI tools to update them, and since every app will implement it in their way, we’re essentially writing a bunch of code for something that will almost never be used and need to be customised every time. Every app that auto-updates needs the same thing: an appcast, and we already have some support for that. It makes much more sense to leverage that: it’s the same system for every app and many more of them have it (for example, every app released through github automatically has it). |
Do Microsoft Office AutoUpdate, Adobe Reader, Adobe Flash Player, Adobe Shockwave Player, Oracle's Java Runtime Environment and Development Kit, Microsoft Silverlight, and Lego Digital Designer, to name a few apps, all have appcast URLs, then? |
Yes, likely they do. They need to know of updates some way, and that is the most likely manner. Just because the casks might not yet have those, it doesn’t means they don’t exist. It doesn’t even matter. If an app auto updates, it auto updates. What’s the sense in making it auto update via CLI? Adding extra code for something that needs to be customised for every app for something they do themselves is non-sensical, and we have a ton more stuff that has priority over that. That feature will likely never be implemented, and we’re certainly not going to discuss it further now. When we get to the point in the project this would even be feasible, it will already be so different all the discussion on this will be irrelevant. This is a “no” for this feature. Perhaps in the future we can discuss it again, but not now, and even the it is unlikely it’ll be done. It isn’t worth it. |
No, no, NO! That's not what I meant! I don't want Homebrew Cask to create its own mechanism for updating apps that auto-update themselves, I want Homebrew Cask to be able to interface with these apps' pre-existing auto-updaters! The reason I mentioned command-line and scripting-based interfaces is because those mechanisms are what I initially thought of as feasible implementations for possible future discussion. Anyway, given that this was a 'pie in the sky' kind of feature request in the first place, I'll drop the subject for now, but let me know if anybody ever comes back and actually does any work toward something like this. |
That’s what you’re not getting: those are the same thing. Since every app will implement their own update mechanism, then our way of interfacing with them must be adapted on a case-by-case basis. And again (and hopefully for the last time) most apps don’t have CLI apps for that (why would they) and if they auto-update, they auto-update, there’s no point in duplicating their automating functionality. |
Oh, right; doh/facepalm. Here's the thing about auto-updaters, though: their schedules tend to be interrupted if you don't leave your computer on constantly (seeing as I boot my family's iMac to an external drive which nobody else uses, I don't;) and most, if not all, of the auto-updaters I've come into contact with, including those I mentioned, tend to have trouble displaying update notifications on time (sometimes they take a day or two to show up!) and don't actually run installations unless you explicitly invoke them. I tend to circumvent these problems by going in and invoking the auto-updaters manually on a daily basis even though most of the time I get a 'This application is up to date'-style message, so les's just say that if more app auto-updaters had methods for invoking them from other programs, then it would be very nice if Homebrew Cask could use them for you, and I, in particular, would definitely take advantage of this functionality! The fact that each such interface would probably be different, though, would, as you assert, most likely be a hard issue to contend with (unless, perhaps, we got more application developers to manage their own applications' own Casks, but that's also highly unlikely.) |
Until that “if” becomes a reality, there is no point in discussing the feature further. |
Yeah, that would probably only happen if there were more use cases for such functionality than just this one package manager. Oh, well, it was a nice thought while it lasted… |
As stated in this comment on Issue #13201: 'Changes to
homebrew-cask
installation behavior', I was wondering if the:auto_updates
stanza described in that issue and further implemented by the pull request accompanying Issue #13969: 'Add:auto_updates
stanza for Casks' might ever be extended to make Homebrew Cask run application auto-updaters automatically via either a command-line or a script-based interface for applications that have them. Given this reply to that comment in the same issue, though, I suspect that somebody will take the liberty of marking this issue with the 'Feature Request' tag. I'm perfectly fine with that, of course, especially given the changes Cask is going through right now and might go through in the near future, but perhaps we could at least start discussing how said feature request might end up being implemented once somebody (maybe even me — if, that is, I ever get around to learning Ruby…) gets around to doing so?The text was updated successfully, but these errors were encountered: