-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add command aliases #2390
Add command aliases #2390
Conversation
@ryfu-msft / @JohnMcPMS - Do you have any recommendations on how I should modify the |
@denelon for this potential change to the user interface. Just want to make sure that he is aware and agreeable to the aliases being added. I assume that many of these are less about the amount of typing and more about offering more verbs for a more intuitive experience. There has been a lack of rigor (mostly from me) about completion, with many new features not being added. I'm not going to hold you to it, but now that I've started thinking about it I see it more. I would think that the tests should be able to steal from the way that the aliases for arguments are verified: winget-cli/src/AppInstallerCLITests/Command.cpp Lines 91 to 93 in 888b4ed
[Edit] |
I was thinking this, but I wasn’t sure quite how to implement it given that arg aliases are all strings, and I chose to implement this as a vector
I can fairly easily add a method to get all of the aliasFullNames as a vector, and create a method for |
I've seen plenty of feedback in this area with the list of Issues. I think it will help in terms of muscle memory for users coming from other package managers. Can we get a table of the original command and the aliases in the description? That would help with consistency when release notes come out. How are aliases to be discovered? Maybe:
I expect these would only impact the CLI and not the PowerShell cmdlets as those have a discrete set of approved nouns and verbs. |
Agreed, no change to PowerShell. |
Agreed with all points |
I added command aliases to completion
Added to the command help per the proposal
|
Pie in the sky idea: What if instead of adding the aliases, we add a feature where users can create their own aliases, like git does? |
I could see something like that as a part of the settings.json file. It's an interesting idea. I'd expect we would need to be fairly strict when defining those aliases, but I like it. |
I think that having that option as a user setting would be good; I think that a combination here would be best, where default aliases are specified as they are here, but if a user specified one that conflicted with a pre-defined alias, the user-defined alias would take precedence. But, I think overall it's an interesting idea and could be a good feature in addition to the standard aliases |
|
I suggest that #2302 is considered as well. I feel like user scope and machine scope could also be aliases when installing a package (with |
If you want to find aliases, I think NPM does a great job with their aliases. They make it so that if you make a typo like
That might be considered butchering the aliases, lol. Otherwise we could have this mechanism that says "did you mean ...", however, I think most of the time the author really means it. A lot of those typos could picked up by the program as known combinations. If we want to keep the command space mostly free, then those can be yield an error, so no one relies on them. However, I think they could ideally always point to install. Another type of alias that I want to mention is adding
|
Those are flags, and not commands. Therefore, they fall outside the scope of a command alias and cannot be considered as part of this PR |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
I think I missed a type conversion in the test; I don't think std::string_view can be implicitly cast to std::string; If the build fails, I'll push a fix |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
winget find
should be a synonym ofwinget search
#1299winget remove
as an alias command forwinget uninstall
#1978I have tested that this is functional, and that alias collisions do not occur when commands are at different levels. E.g -
winget add <params>
does not conflict withwinget source add <params>
.I need some guidance on how to implement the unit tests for this - mainly just how to modify the
EnsureCommandConsistency
test. I presume that the command consistency will need to check against command full names, and that command aliases will have to have a method added to get the alias full name, but I'd like some help and guidance before making those changesMicrosoft Reviewers: Open in CodeFlow