Subcommand aliases

[danielbayley]

Is your feature request related to a problem? Please describe.
mas could use a few aliases, to bring it more in line with brew and cask…

Describe the solution you'd like
These could include:

• mas -v/--version -> mas version
• mas -h/--help -> mas help
• mas ls -> mas list
• mas i -> mas install
• mas rm -> mas uninstall
• mas upgrade -> mas update
• mas purchase -> mas install <with arguments> (after install is updated to "purchase")
• mas signin -> mas sign-in
• mas signout -> mas sign-out

REJECTED:

• mas update -> brew upgrade mas

[phatblat]

Good idea! These would be easy to add.

[danielbayley]

These would be easy to add.

@phatblat I imagine so… although I haven't dug into Swift yet… If you point out where in the codebase, I can do a PR…

[phatblat]

This project uses Commandant and all the commands live in the Commands folder. I don't see an option in Commandant for creating a command alias. However, you could:

1. Duplicate the classes
   • e.g. copy List.swift to Ls.swift and change the verb to ls
2. Add the new command class to the registry main.swift

[danielbayley]

This project uses Commandant and all the commands live in the Commands folder. I don't see an option in Commandant for creating a command alias. However, you could:

1. Duplicate the classes

   • e.g. copy List.swift to Ls.swift and change the verb to ls

2. Add the new command class to the registry main.swift

@phatblat Ok, quickly done that for i, ls, rm/remove, and a rough implementation of update in #283… Not sure how to deal with -v/--version, or -h/--help within the context of the Commandant framework though?

[muescha]

the -v/--version, or -h/--help are flags and options in the Commandant system

[muescha]

just copy over the command looks not good as coding style - i would create a wrapper command for alias and wrap them in this command - so no duplicate code is created

see comment here: Carthage/Commandant#155 (comment)

if the alias command not goes into commandant - we can add it anyway into the mas codebase

Note: duplicate code is bad, because if someone change the code most time they forget to edit the "copied" code part)

[rgoldberg]

@mas-cli/contributors Commandant is dormant, without updates for 4 years.

Apple now provides the open source Swift Argument Processor, which supports aliases and is actively being developed.

I imagine switching shouldn't be hard. Is it OK to switch?

Various other command line issues exist, like validating arguments, improving help messages, and generating bash, zsh, and fish completion scripts. It probably makes sense to switch over ASAP, so we don't do unnecessary work that will either need to be redone or that Swift Argument Parser can automatically do for us.

Does anyone disagree? Are there other better frameworks?

[rgoldberg]

@mas-cli/admins

I've locally refactored mas to use SAP instead of Commandant.

To get everything working, I moved everything from MasKit into mas. Only the mas executable target still exists (it now produces an mas Swift module); the MasKit library target (& its associated Swift module) is gone. I had to update swift-tools-version from 5.3 to 5.5.

Is there any need to retain MasKit, given that I got testing to work without a separate library?

Is it OK to have upgraded swift-tools-version from 5.3 to 5.5?

I also had to remove swift-format from the dependencies because that forced an older version of Swift Argument Parser.

The code doesn't use swift-format; it is only used by the lint & the format scripts. I switched it to just running swift-format from the command line, which makes more sense. The dependency might have been to download different versions of swift-format for different Swift versions dictated by different macOS versions, but that should be handled by the brew swift-format formula, or by a tap if we need functionality outside of what the formula provides.

[phatblat]

The main reason most of the mas code was moved into a MasKit framework was because it hasn't been possible to unit test an Xcode CLI executable. That was before the Xcode project was replaced with a swift package build. If we can test the code in a Swift package without the code in a separate framework, then that makes MasKit framework obsolete. I don't know of any other project using the framework.

[rgoldberg]

@phatblat I've already moved all the mas code into the mas exectuableTarget, and done away with MasKit, as some newer version of Swift (5.4, IIRC) allowed executable code to be tested.

I've already switched from Commandant to Swift Argument Parser. I haven't created any new aliases yet, though they're easy to add in Swift Argument Parser. Was waiting to have a complete list of aliases drafted here.

One preference: I'd like to rename upgrade as update, then create an upgrade alias for update, because the MAS uses the term update, but not upgrade, throughout. I'd like to follow the MAS terminology as much as possible, as long as it is understandable by normal users.

[phatblat]

Renaming upgrade to update is fine, especially if there's an alias for the old name. I don't recall who came up with the original name of this action, but it was more aligned with brew terminology than the App Store's.

[phatblat]

IIRC, homebrew-bundle uses mas command output to interact with the tool. In order to avoid breaking it, the ideal path would be to:

1. Add JSON output support while maintaining the same text output as the default.
2. Work with homebrew-bundle to migrate the tool to use the JSON output
3. Make any breaking changes to mas default text outout.