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 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.