Draft Roadmap: brew cask upgrade

[rolandwalker]

Explanation

brew cask upgrade is frequently brought up on IRC, and there have been a few different issues and PRs where it is discussed (long-running: #309).

brew cask upgrade is a high priority to me. Homebrew-cask is not really a package manager without upgrade. It is also important that when we do ship an upgrade verb, it actually works.

There are many prerequisites for our infrastructure to support a brew cask upgrade that works reliably, and a few things that should come along with it.

For the benefit of our users, and anyone who wants to participate in coding, here is a general roadmap that shows what some of us have been working on, and where we can go over upcoming months. I plan to edit this comment in-place over time.

Why is so much attention paid to tokens and versioning? Because Homebrew-cask uses a simple filesystem-as-a-datastore approach in which Cask tokens and version numbers are used as directory names. We need to standardize tokens and versions so that files are stored in a predictable place on disk — and because there is no facility to handle renames sensibly.

This is only a draft. It is possible that there is disagreement among the maintainers about certain items.

Current Implementation

Homebrew-cask is very good at installing, inconsistent on uninstalling, and mostly-incapable on upgrading. Part of upgrading is implicit uninstalling, so uninstall must be made to work equally well as install does.

Roadmap

• Standardize Cask tokens in repos (2090/2467)
  • Standardize tokens for app Casks (1312)
  • Standardize tokens for font Casks (778)
  • Standardize tokens for Casks in homebrew-versions (102)
  • Standardize tokens for pkg Casks (179)
  • Standardize tokens for prefpane Casks (24)
  • Standardize tokens for qlplugin Casks (22)
  • Standardize tokens for manual-installer Casks (13)
  • Standardize tokens for binary-only Casks (10)
  • Standardize tokens for Casks in homebrew-unofficial (8)
  • Standardize tokens for colorpicker Casks (6)
  • Standardize tokens for screen-saver Casks (6)
  • Standardize tokens for widget Casks (3, unimportant because they don't work) (support for widgets has been removed as of Remove support for widgets #8751)
  • Standardize tokens for service Casks (2)
  • Standardize tokens for input-method Casks (1)
  • Standardize tokens for none-of-the-above Casks (1, adobe-air.rb)
• Standardize Cask version numbers in repos (778/2467)
  • Standardize version numbers for app Casks (1312)
  • Standardize version numbers for font Casks (778)
  • Standardize tokens for Casks in homebrew-versions (102)
  • Standardize version numbers for pkg Casks (179)
  • Standardize version numbers for prefpane Casks (24)
  • Standardize version numbers for qlplugin Casks (22)
  • Standardize version numbers for manual-installer Casks (13)
  • Standardize version numbers for binary-only Casks (10)
  • Standardize tokens for Casks in homebrew-unofficial (8)
  • Standardize version numbers for colorpicker Casks (6)
  • Standardize version numbers for screen-saver Casks (6)
  • Standardize version numbers for widget Casks (3, unimportant because they don't work) Support for widgets removed as of Remove support for widgets #8751
  • Standardize version numbers for service Casks (2)
  • Standardize version numbers for input-method Casks (1)
  • Standardize version numbers for none-of-the-above Casks (1, adobe-air.rb)
• Algorithmic token-generation and versioning
  • formalize token generation (doc: Canonical name == App bundle name #2659, drop non-alpnanumeric chars from Canonical Name #3175, Drop generic terms from ends of Canonical names #3255, doc: drop version numbers from end of Cask names #3285, should "client" be removed from the end of Cask names? #3305, proposal: prepend vendor on naming collisions #3344)
  • write generate_cask_token script to generate tokens (devscript: add cask_namer #3443)
  • real-world testing period for generate_cask_token script
  • roll current generate_cask_token script logic into brew cask create
  • add version-number determination to generate_cask_token
    • proposal: for app bundles, pull the version number from Info.plist
  • add version-number determination to brew cask create
• All pkg-based Casks must have uninstall stanzas
  • complete tracking issue at Casks which lack uninstall stanza #3322 (almost finished, thanks to @alebcay)
  • add a brew cask audit test to keep out any new entries without uninstall
• Make the uninstall stanza available to all Cask types
• Nail down changes to the DSL
  • it will always be possible to add to the DSL, but it will become more difficult to remove from the DSL
  • remove md5 stanza (remove md5 checksum support #2931)
  • remove sha1 stanza (Retire support for sha1 stanza. #4264)
  • remove no_checksum stanza (retire support for no_checksum stanza #4689)
  • tracking issue for further DSL changes (Roadmap: Rationalizing and Extending the Cask DSL (DSL 1.0) #4688)
• Use appcasts to detect updates
  • add appcast stanza to DSL (add optional appcast stanza to DSL #3105)
  • snapshot appcast content and wait several weeks for real-world comparisons (was done for ~200 Casks on 3 March)
  • find standard Sparkle-based appcast URLs for all app Casks (Add appcast stanzas for 186 latest-style Casks #4412, add appcast stanza for 78 Casks #4646, add appcast stanza for 27 Casks #4648, add appcast stanza for 70 Casks #4674, add appcast stanza for 77 Casks #4780, add appcast stanza for 28 Casks #4783, add appcast stanza for 18 Casks #4829)
  • find non-standard/non-Sparkle appcast URLs for all other self-updating apps (eg GitHub.app)
    • recently-added link Casks
    • non-link Casks
    • Casks that use Sparkle with small modifications (check for Sparkle.Framework inside the App bundle)
    • Casks that use Sparkle with SUFeedURL set to SET_PROGRAMMATICALLY_BY_APPLICATION_HELPER
    • Casks that use non-Sparkle appcasting
    • Casks that had Info.plist in unexpected location
  • extend appcast stanza to support sha256 hashes
  • store expected appcast hashes inline with Casks
  • ability to show appcast status in brew cask list
  • generate automatic notifications to maintainers on appcast update
  • start checking incoming Casks for appcasts routinely
    • without imposing load on Cask authors
    • brew cask create could do this if it is pointed at an app bundle
• Migrate as many 'latest'-scheme Casks to version numbers as possible
  • prediction: we will never be able to entirely remove the 'latest' scheme
  • migrate to versioned download URLs revealed by appcasts
  • migrate to versioned download URLs revealed by HTTP redirects
  • migrate to versioned download URLs revealed by metadata?
    • new devscript to support this: list_url_attributes_on_file
• Support for a ~/.brewcaskconfig file
  • git-style format
  • bundle a license-compatible library as was done for the plist parser, or roll our own
  • the CLI should be able to write to the config file as with git
  • support for environment variables should be REMOVED
• Bookkeeping: keep records of what was done at install-time, as in Store metadata with installed Casks. #3066
  • add new command verb to display the install record for a given cask
• Make brew cask uninstall refer to the previously recorded Cask/version, rather than the current repo
• Expose discrete installation phases with new command verbs
  • fetch (CLI - Fetch #2970)
  • stage
    • part of the reason to separate out staging is to implement brew cask audit --stage
  • preflight (fairly unimportant)
  • link
    • ability to re-link already installed Cask
    • ability to un-link Cask without removing it from Caskroom
  • postflight
  • zap (new functionality; zap phase not implicit under default install)
• New command verb to dump a shell script which will re-create the existing install
  • desirable feature: option to use stored metadata instead of implicitly upgrading
• New command verb to rename versioned Caskroom directories to match in-place updates performed independently by apps
• brew cask audit --stage
  • needed if we are going to start depending on Info.plist
• New command verb outdated ([WIP] brew cask outdated #9490)
  • consult Info.plist as well as versioned directory name
  • leave room for the planned feature of managing multiple installed versions
• Ability to remove currently-installed, but outdated (unlinked) versions.
  • interface could be through brew cask cleanup as suggested in Delete old versions in cleanup #4651
• New command verb upgrade
• Update HACKING.md re: upgrade verb

[alebcay]

Have we considered using the milestones function on GitHub for help with stuff like this?

[rolandwalker]

It's a good idea, though I don't find them to be that handy in practice.

Milestones are like a special type of label which you can apply to an existing issue. I would have to open a bunch of separate new issues for all the notions here, then assign each to the milestone, which is a lot of clicking. Then, each reader has to click on all the items to read them, which makes it harder to see the big picture. In addition, discussion gets scattered into the various sub-issues and sometimes goes un-noticed.

Lastly, I included some things in the overview which are related work, but are not blocking the milestone.

[rolandwalker]

Let's also call upon the mysterious @phinze.

[danielb2]

Support for a ~/.brewcaskconfig file

My vote is for following the convention .config/<appname>/<files>

Example: .config/homebrew-cask/settings.yml

[rolandwalker]

@alebcay looks like GitHub made milestones a lot more useful now.

[fgarcia]

I've just adapted one of the scripts to just list outdated casks, and realized that I do not want certain apps be upgraded by cask: Google Chrome being a clear example for its automagical self upgrade.

This is a minor issue, but maybe it is worth considering adding brew pin to the roadmap for this feature.

[rolandwalker]

The DSL changes all got done, but I am no longer working on this roadmap.

[leipert]

Wait. Does this mean there will be no brew cask upgrade in the foreseeable future?

[vitorgalvao]

There are plans (that need a bit more discussion and an official announcement I’ll need to write up) to change homebrew-cask’s behaviour from linking to copying (long story short, linking sucks for GUI apps and we’re just building workarounds on top of workarounds, making it an incredibly broken model), so upgrade (which was moving slowly anyway) will have to be revised anyway.

[szhu]

Good to hear that links are going away! Can you link to gh issues surrounding this change?

[vitorgalvao]

There are none yet, @szhu. But don’t worry I didn’t forget about you. At the moment this is just an idea that hopefully will be discussed and set in march soon. I strongly believe it’s the right one, though.

[szhu]

I actually forgot that I wrote that, thanks :)

[tjnycum]

There are plans (that need a bit more discussion and an official announcement I’ll need to write up) to change homebrew-cask’s behaviour from linking to copying (long story short, linking sucks for GUI apps and we’re just building workarounds on top of workarounds, making it an incredibly broken model), so upgrade (which was moving slowly anyway) will have to be revised anyway.

At the moment this is just an idea that hopefully will be discussed and set in march soon. I strongly believe it’s the right one, though.

Please wait for open discussion of that before you make up your mind. I'm under no illusion that there's a perfect solution—each option has its strengths and weaknesses—but I find the idea that requiring everyone to keep two copies of every app they install via cask is the best course of action very difficult to swallow.

[vitorgalvao]

Plans will be posted soon (should be today or tomorrow). No one is talking about keeping two copies, though, “copy” is a throwback to how we referred to the feature in the past, it doesn’t mean duplicating stuff (actually, we’ll take less space in some cases).

Linking has shown to be a subpar solution for this, so keeping that is not an option. For homebrew-cask to evolve in other areas, we need this change: it’ll solve a bunch of issues right of the bat. Will it introduce new ones? We’ll have see how it evolves.

I’ll go into all the reasoning at length in the announcement, though (it’ll be a regular github issue). Please also don’t think there hasn’t been open discussion on this — there has (like the issue I linked to before). A big part of the reasoning to do it the current way has been ideological but that approach isn’t working.

The goal of homebrew-cask isn’t changing, though, but it is time to try a different solution.

[salimane]

+1

[vitorgalvao]

@salimane Please stop spamming issues. This is closed, don’t +1 it, or any other issue for that matter, it won’t make issues get worked on faster (or at all).

[salimane]

@vitorgalvao you're right, this was closed :)

[gripedthumbtacks]

So what is the actual solution???

[chilloutman]

Here's a workaround that mostly works:

brew cask list | xargs brew cask install

I'm pretty sure a propper solution is WIP.

[gripedthumbtacks]

for app in $(brew cask list); do cver="$(brew cask info "${app}" | head -n 1 | cut -d " " -f 2)"; ivers=$(ls -1 "/opt/homebrew-cask/Caskroom/${app}/.metadata/" | tr '\n' ' ' | sed -e 's/ $//'); aivers=(${ivers}); nvers=$(echo ${#aivers[@]}); echo "[*] Found ${app} in cask list. Latest available version is ${cver}. You have installed version(s): ${ivers}"; if [[ ${nvers} -eq 1 ]]; then echo "${ivers}" | grep -q "^${cver}$" && { echo "[*] Latest version already installed :) Skipping changes ..."; continue; }; fi; echo "[+] Fixing from ${ivers} to ${cver} ..."; brew cask uninstall "${app}" --force; brew cask install "${app}"; done

[tonyseek]

My adhoc solution: https://gist.github.com/tonyseek/afa5902eb2713ca6cfab

[gripedthumbtacks]

@tonyseek yeah i had implemented a hack one-liner above very similar to your with exception of default path not being checked ;)

[a0s]

Simple cleaning based on ctime https://gist.github.com/orangeudav/29a58c8df6446a87c50ec035b2b5dfcd

[RandomDSdevel]

@orangeudav: What does your scripted alternative to brew cask cleanup have to do with this thread, where we're discussing ways to make up for Homebrew Cask's lack of a brew cask upgrade command?

[gripedthumbtacks]

Does not my little hack work for you?

https://gist.githubusercontent.com/9Yg1rxeSeha90ZU1/7d66cf35bae4c8d251bfd4185575a80b/raw/1e9fde8caba83fb18578ea859f0a10270ebc1b0b/brew.cask.upgrade.sh

[vitorgalvao]

This is a closed issue. There have been already a bunch of workarounds posted by people. No more are needed. What we need is a native solution.

Please stop spamming our inboxes with the same alternatives with variable results. Locking.

[vitorgalvao]

#29301