Towards an automatic update mechanism

[doits]

Initial parts of determining the current installed version of an app and a hint whether an update is available or not.

Next step would be to implement automatic updating with brew cask update or hook into brew update. Besides this, the installed? command must return true even when an old version of an app is installed (might have side effects?). Tests are missing atm, too.

Posting this as a PR just to discuss it and to determine whether it is going into the right direction.

[doits]

brew cask upgrade and brew cask outdated implemented initially. Tests still missing.

[rolandwalker]

Hi! Much respect to you @doits, for speaking with code!

All of us want to have brew cask upgrade. However, the approach this PR is not really robust. It also changes the DSL more than needed, and would put burdens on first-time Cask authors.

I see you discovered one of the fundamental problems, which is that version numbers are currently decided "artistically" by the Cask author, and may not coincide with the version number defined in the app bundle.

You should know that the maintainers are working toward the same end-goal as you are here, and that there is more-or-less a plan (if not a schedule). The way we are approaching it is bottom-up, adding each needed building-block on the back end. When we finish that, you will be able to write a robust brew cask update, because you will have access to the right tools and abstractions.

For instance, #3066 provides one of the needed puzzle-pieces for a robust uninstall and update mechanism.

Similarly in #2659 and followups, I am trying to make the Cask name systematic and not "artistic". When that is accomplished, I plan to do the same thing for version numbers.

If you want to help out coding up those building blocks, that would be awesome --- please get in touch on IRC and we can coordinate our efforts.

If you would rather work independently within the limitations of the current codebase, check out the possibility of writing your own "external command": #2594.

[doits]

@rolandwalker thanks for the tip of the external command (missed it) - might be the shortest way for me to get this running while the safe upgrade process is being worked on. This here was just some quick hacking on an unknown codebase to see where I could go without.

Nevertheless you are right about the needed changes of the DSL. My proposal with the update_version and check_version_cmd is mainly because of the latest, beta casks etc. I'd rather kill those at all (then there'd be no need for those changes), but there was another discussion in #1021 that sometimes only the latest version is available to download. And when pointing to the latest url something other/newer than the version specified could be installed. So basically for those Casks we even do not know what we install (which is fatal the longer I think about it - homebrew-casks installs something on an user's computer automatically but does not even verify that it is really that what it wants to install and not some hijacked whatever?).

So maybe I'll refactor the main parts of this PR into external commands (so merging changes will be easier). I'll follow the discussions about implementing a safer upgrade process and discussions about latest and not latest casks and maybe sporadically hack on the code (as I did with this PR).

[doits]

I updated the PR to be more simple (no DSL change) but to only work with versioned casks. Check for whether the version provided is a regular version and not latest or something else is still ugly, but that way at least versioned casks can be upgraded while others are simply ignored.

Maybe this can be used as a base to go for a safe upgrade process.

[rolandwalker]

Yes, your updated version is way simpler and better. Because there is no DSL change, you could definitely develop both of these as external commands.

If you get something going, you could think about/work on interfaces (my head isn't on interfaces now, but on plumbing).

We might consider accepting an outdated verb into the main codebase after #3066 is merged.

And, by the way, #3105 was submitted since I last commented here, and is also relevant to your work.

PLEASE DO keep in touch.

[doits]

I already created a gem to have this run as external commands (prefixed by d):

https://rubygems.org/gems/brew-cask-commands

To install it on osx:

sudo /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/gem install brew-cask-commands

The this works then:

brew cask doutdated
brew cask dupgraded

I'll keep in touch with this project and contribute code if my spare time allows it.

[rolandwalker]

Awesome! I'd like to put at least your doutdated script into developer/examples, as it is much better than what I provided there originally.

Can I hack that together into a single file and add attribution, or would you be willing/find the time to make a PR?

[doits]

If you ask like this ;-) Sure, hack it together in one file and put it in the examples dir, no problem for me.

[simonweil]

👍

[karbassi]

👍

[josephholsten]

@rolandwalker what's the recommended way to use doutdated? should I use @doits' gem?

Also, are the #3066 and #2659 still the top of the iceberg for contributing to the Right Way for an update command?

[vitorgalvao]

Closing as this no longer makes sense and will need to be rethought.