brew bundle: use 'mas get' instead of 'mas install' for Mac App Store apps

[onnimonni]

Problem

brew bundle uses mas install for Mac App Store entries in the Brewfile. However, mas install only works for apps previously associated with the Apple Account — it fails with:

Error: Redownload Unavailable with this Apple Account

This affects even universally free apps like Keynote, Numbers, and Pages on fresh Apple Accounts that have never downloaded them.

Current mas CLI behavior

• mas get (alias: mas purchase) — acquires and installs apps, works on fresh accounts
• mas install — only re-downloads previously acquired apps

From mas help:

get, purchase    Get & install free apps from the App Store
install          Install previously gotten apps from the App Store

Proposed change

Change mac_app_store_installer.rb to use mas get instead of mas install for initial installs. This would make Brewfiles work on fresh machines/accounts without requiring users to manually pre-install each app.

A possible approach:

1. Try mas install first (fast path for already-associated apps)
2. Fall back to mas get if install fails with the redownload error

Or simply always use mas get which handles both cases.

Use case

Using a Brewfile to set up a new Mac for someone. All masApps fail because they were never previously downloaded on that Apple Account. The workaround is to manually run mas get <id> for each app before brew bundle, which defeats the purpose of automated setup.

Relevant code

https://github.com/Homebrew/brew/blob/master/Library/Homebrew/bundle/mac_app_store_installer.rb

[MikeMcQuaid]

Or simply always use mas get which handles both cases.

If this always works: seems better! CC @rgoldberg as this seems like a regression

[rgoldberg]

Always using mas get should work fine.

mas get (aka mas purchase; an alias exists, so mas get & mas purchase are equivalent; "get/got/gotten" is synonymous for "purchase/purchased/purchased") should work in all cases for which mas install works.

There shouldn't be any regression here; I think the following (and similar verbiage) was potentially confusing in the description/body of this issue:

without requiring users to manually pre-install each app

mas install doesn't (and didn't ever, at least to my knowledge) require apps to have been previously installed; they must have been previously gotten/purchased by the Apple Account that is currently signed into the App Store (mas uses the terms "get/got/gotten" because the text on the button to get/purchase a free app from its App Store page is "Get"). i.e. mas get performs the equivalent to clicking on the Get button on an app's App Store page; if the app was already gotten/purchased, there should be no difference in the end results between mas get & mas install.

"get/got/gotten" might also be confusing for some; I was just trying to adopt as much terminology as possible directly from the App Store / the iTunes Search web API , hence the following synonyms being added:

mas get > mas purchase
mas lookup > mas info
mas vendor > mas seller
mas update > mas upgrade

[MikeMcQuaid]

Thanks both. Yes, I can see why this wouldn't be a regression then. Fine with me to use get instead.

@rgoldberg any downsides on always using get vs. install?

[rgoldberg]

I don't know of any downsides to using mas get instead of mas install. I strongly suspect that there aren't any downsides (or any upsides besides mas get getting & installing previously ungotten free apps), but I cannot give a 100% authoritative answer because their respective core functionalities are provided by the undocumented Apple StoreFoundation private framework.

There are only 2 differences between the 2 commands that might affect their functional behavior, both of which are configuration settings for the SSPurchase object used to install/update an app:

1. get sets SSPurchase.isRedownload to false; install sets it to true. I suspect that this doesn't affect the outcome any way (e.g., if the values were reversed, I doubt that it would matter), but I don't know for sure.
2. get uses pricingParameters=STDQ&macappinstalledconfirmed=1 in the buy parameters query string; install uses pricingParameters=STDRDL. The settings have been used since the respective functionalities were added to mas before my involvement.
   1. I don't know exactly what macappinstalledconfirmed=1 does or if it changes the outcome.
   2. STDQ & STDRDL signify standard quality initial download & standard quality redownload, respectively. The quality terms stem from app downloads having been shoehorned into a system originally used for downloads like iTunes music & videos, which have different quality levels. STDQ gets a free app if it wasn't already gotten, while STDRDL doesn't. I don't know if there are any other functional differences between the 2 values.

[onnimonni]

mas install doesn't (and didn't ever, at least to my knowledge) require apps to have been previously installed

This case happened when I helped my friend to setup their machine with my nix-darwin setup which forwards App Store installations to brew bundle.

We got just app store opened when running the brew bundle and the Error: Redownload Unavailable with this Apple Account error for my friend because this was a fresh apple account.

It did work finally when we:
1. Logged into the App Store
2. Allowed installing software without asking permissions
3. For loop each app id with mas get $id
4. running the brew bundle

But I wish that the step 3 can be removed from the future users 👍