Install via app name / use tab completion to get app ID from name

[mcandre]

For convenience, could mas install "Some Cool App" automatically lookup the numerical identifier? Kinda stinks that users are expected to manage this information on behalf of mas.

[dotCipher]

Agreed, functionality like that would be awesome.

[mcandre]

Go ahead and lookup the ID when the user searches for an application, and then invoke the install phase using that ID. Do this on behalf of the user. This is some dumb shit right now.

As a workaround, users can:

$ mas search '<application name here>' | awk '{ print $1 }' | xargs mas install

[brianbrownton]

This is a little more complicated in many cases, with respect to @mcandre's comment in particular. Search isn't deterministic, as sometimes more than one result will come back.

$ mas search quip
1003160018 Quip 
1002623276 Quiplash

So even if you wanted to install quip here, you might run into unexpected situations.

[dentarg]

v1.4.0 has implemented this with the mas lucky command (#88)

[mcandre]

@brianmorton This is why an exact name should be used.

[phatblat]

#100 changed the upgrade command to work with app names or IDs. I agree that install should work off app names with IDs also supported for backwards compatibility.

One potential complication is the fact that app names in the app store can change and also can sometimes be quite long. It would be nice if there were a way to have unique tokens for each app like what Homebrew cask uses. But, I'm not sure how that could be managed as mas doesn't control the app name data. In any case, we could support exact app name matches without much work.

[bgibson72]

Is there a way to install previous versions of macOS? If I search the app store with mas search, I get the latest version which I do not want. I'd like to grab 10.13.3 or even 10.13.0 rather than 10.13.5. Thanks!

[phatblat]

@bgibson72 It is possible to download installers for previous minor versions of macOS (see comment on #106) since each of these has a unique ID in the Mac App Store. However, I don't believe it's possible to download older patch versions of macOS installers as they are simply updates to the same app ID.

[phatblat]

@bgibson72 Looks like there are many updaters on the Apple Support Downloads site. However, I can't tell if these contain a full installer or require that a previous version of macOS already be installed that they simply "update".

[ludwigschubert]

@brianmorton how would you feel about presenting an interactive list of choices in such cases?

[phatblat]

That’s an interesting idea. If the search string results in exact one result, install it. Otherwise stop and present a list.

[brianbrownton]

One potential complication is the fact that app names in the app store can change and also can sometimes be quite long. It would be nice if there were a way to have unique tokens for each app like what Homebrew cask uses. But, I'm not sure how that could be managed as mas doesn't control the app name data. In any case, we could support exact app name matches without much work.

Cask gets around this be acting as a middleman (we provide tokenization rules and name apps in a repeatable fashion so we always know what a given "pretty" name will be when tokenized).

@brianmorton how would you feel about presenting an interactive list of choices in such cases?

I generally find interactive lists to be great UX (which is my background), however most people that opt to use mas switched from a GUI (eg. the app store) to the commandline for a reason - most likely some element of scriptability or automation. Interactive lists can pose challenges to that.

That’s an interesting idea. If the search string results in exact one result, install it. Otherwise stop and present a list.

If you wanted to move forward with this, my suggestion would be to introduce tokenization (like cask) so that names would be tokenized and unique. If that is not palatable, I would then say do the install if the search result is deterministic (eg. the same functionality as lucky), or abort with an error exit code and a list of possible options (eg. did you mean quip (1003160018), quiplash (1002623276 ), etc.)

In my opinion, that is how it would be resolved if this was an issue at hbc, as they strive to make things somewhat backwards compatible (eg. not break existing installations or people using it in a scripted/automated way) while introducing new features.

[phatblat]

@brianmorton regarding tokenization, App Store and iTunes URLs support short links for app names with clearly defined rules for building the URL from an app name. mas currently uses the iTunes Search API for search, lucky and info commands. I suspect these two Apple systems work with the same data, but I haven't seen short links show up in search results so I don't know how mas could confirm that a given token actually corresponds to a specific app because the ID is what's used to initiate the install.

I've been wanting to do some reverse engineering to see what the native macOS API for the App Store looks like because that might open up new possibilities.

I agree that an interactive menu would be problematic for scripting and automation, so if that were added there would either need to be a way to opt in or out (depending on which is used more, I don't have any stats to help decide).

[phatblat]

The app token to app ID mapping could certainly be constructed and stored somewhere, but my worry since the App Store is continuously changing through Apple's processes, there would be lots of issues trying to keep this data up-to-date. I'm hoping we can find a solution that doesn't require maintaining a separate database which will get stale quickly.

[rgoldberg]

This functionality is already supported by mas lucky.

Convenient lookup of deterministic app IDs for any command that accepts ID arguments should be performed by shell tab completion, which should populate the completion list with all app IDs labelled by their respective app name that have been returned from running mas search <current tabbed token>.

Once this has been provided for all supported shells, maybe mas lucky should be removed.

[rgoldberg]

See #541 for supporting bundle IDs in addition to app IDs.

I think that tokenization is a bad idea. Homebrew can tokenize its cask names because each cask is manually created & on a file system. mas deals with millions of apps in the App Store. The setup of the App Store, and all means of interacting with it, are outside of the control of mas. Tokens are completely unnecessary, as users can look up unique app IDs or bundle IDs (the latter can be used iIf we implement #541).

If a user wants to maintain their own tokens, they can set shell environment variables whose values are app IDs (or, post-#541, bundle IDs).

Short links don't necessarily link to only one app. There's no need to support them. Support app IDs, bundle IDs, and lookup of either one (or both) of the IDs via tab completion of app names calling mas search <partial app name>.

[rgoldberg]

Closing in favor of #678