Skip to content

Subcommand aliases #281

Open

Description

@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…

Proposed

  • -v ➡ version
  • ls ➡ list
  • remove ➡ uninstall
  • rm ➡ uninstall
  • get ➡ install <with arguments> (after install is updated to "purchase")
  • purchase ➡ install <with arguments> (after install is updated to "purchase")
  • sign-in ➡ signin
  • sign-out ➡ signout

Implemented

  • --version ➡ version
  • -h/--help ➡ help

Rejected

  • i ➡ install
  • update ➡ brew upgrade mas

Activity

  1. phatblat commented on Jun 13, 2020

    @phatblat
    Member

    Good idea! These would be easy to add.

  2. danielbayley commented on Jun 13, 2020

    @danielbayley
    ContributorAuthor

    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…

  3. phatblat commented on Jun 14, 2020

    @phatblat
    Member

    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
    2. Add the new command class to the registry main.swift
  4. danielbayley commented on Jun 16, 2020

    @danielbayley
    ContributorAuthor

    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

    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?

  5. added a commit that references this issue on Jun 16, 2020
  6. muescha commented on Jun 18, 2022

    @muescha

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

  7. muescha commented on Jun 20, 2022

    @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)

  8. changed the title [-]Aliases?[/-] [+]Subcommand aliases[/+] on Sep 15, 2024
  9. rgoldberg commented on Sep 22, 2024

    @rgoldberg
    Member

    @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?

  10. rgoldberg commented on Sep 25, 2024

    @rgoldberg
    Member

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

  11. phatblat commented on Oct 26, 2024

    @phatblat
    Member

    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.

  12. rgoldberg commented on Oct 26, 2024

    @rgoldberg
    Member

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

  13. phatblat commented on Oct 26, 2024

    @phatblat
    Member

    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.

  14. phatblat commented on Oct 26, 2024

    @phatblat
    Member

    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.
  15. added
    backlogPostponed: requires more info, requires too much effort for payoff, etc.
    and removed on Jan 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    backlogPostponed: requires more info, requires too much effort for payoff, etc.feature

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions