You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Duplicate the classes
e.g. copy List.swift to Ls.swift and change the verb to ls
Add the new command class to the registrymain.swift
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:
Duplicate the classes
e.g. copy List.swift to Ls.swift and change the verb to ls
Add the new command class to the registrymain.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?
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
@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?
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.
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.
@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.
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.
Activity
phatblat commentedon Jun 13, 2020
Good idea! These would be easy to add.
danielbayley commentedon Jun 13, 2020
@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 commentedon Jun 14, 2020
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:
List.swifttoLs.swiftand change theverbtolsregistrymain.swiftAdd i[nstall] alias
Add l[i]s[t] alias
Add remove alias
Add r[e]m[ove] alias
danielbayley commentedon Jun 16, 2020
@phatblat Ok, quickly done that for
i,ls,rm/remove, and a rough implementation ofupdatein #283… Not sure how to deal with-v/--version, or-h/--helpwithin the context of the Commandant framework though?Add update alias
muescha commentedon Jun 18, 2022
the
-v/--version, or-h/--helpare flags and options in the Commandant systemmuescha commentedon Jun 20, 2022
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
mascodebaseNote: duplicate code is bad, because if someone change the code most time they forget to edit the "copied" code part)
[-]Aliases?[/-][+]Subcommand aliases[/+]rgoldberg commentedon Sep 22, 2024
@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 commentedon Sep 25, 2024
@mas-cli/admins
I've locally refactored mas to use SAP instead of Commandant.
To get everything working, I moved everything from
MasKitintomas. Only themasexecutable target still exists (it now produces anmasSwift module); theMasKitlibrary 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-formatfrom 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 brewswift-formatformula, or by a tap if we need functionality outside of what the formula provides.phatblat commentedon Oct 26, 2024
The main reason most of the
mascode was moved into aMasKitframework 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 makesMasKitframework obsolete. I don't know of any other project using the framework.rgoldberg commentedon Oct 26, 2024
@phatblat I've already moved all the mas code into the
masexectuableTarget, and done away withMasKit, 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
upgradeasupdate, then create anupgradealias forupdate, 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 commentedon Oct 26, 2024
Renaming
upgradetoupdateis 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 withbrewterminology than the App Store's.phatblat commentedon Oct 26, 2024
IIRC, homebrew-bundle uses
mascommand output to interact with the tool. In order to avoid breaking it, the ideal path would be to:masdefault text outout.