Conversation
| @@ -1357,7 +1357,8 @@ Please specify one of them using the `--source` option to proceed.</value> | |||
| <value>Portable install failed; Cleaning up...</value> | |||
There was a problem hiding this comment.
I really want to sort this file alphabetically but I know VS is just going to mess it up again...
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
@Trenly: interesting, when I tested it, I got a very different result: check-spelling-sandbox#2 (comment) (this comment has since been collapsed, but you can expand it). From looking at the logs (here and there), I suspect that checkout-merge step is not doing the right thing tm. Here'a a rebased run: And here's me trying to reproduce this PR as it was: I'm going to have to investigate the checkout-merge logic, it feels like it isn't quite behaving. Can I ask that this be rebased after #2739 is merged? (Preferably squashing 74a97e6 into 1ede614 -- when I did a rebase, I tripped on a conflict there...) |
cc514f7 to
cbb64b9
Compare
This comment has been minimized.
This comment has been minimized.
|
|
||
| ### pinning | ||
|
|
||
| This feature enables the ability to pin packages to a specific version to prevent the Windows Package Manager from updating them. |
There was a problem hiding this comment.
nit: it does not have to be a specific version
| struct SourceListCommand final : public Command | ||
| { | ||
| SourceListCommand(std::string_view parent) : Command("list", { "ls" }, parent) {} | ||
| SourceListCommand(std::string_view parent) : Command("list", parent) {} |
There was a problem hiding this comment.
Will this actually remove the "ls" change done in previous pr during merging?
There was a problem hiding this comment.
Yeah, I messed up the rebase. I'll revert this.
| Argument::ForType(Args::Type::Source), | ||
| Argument::ForType(Args::Type::CustomHeader), | ||
| Argument::ForType(Args::Type::AcceptSourceAgreements), | ||
| Argument::ForType(Args::Type::Force), |
There was a problem hiding this comment.
Curious what is the scenario for --force in pin add?
There was a problem hiding this comment.
The scenario I was thinking of is overwriting the pin. Like winget pin add Pkg adds a pin, then winget pin add Pkg --version 1.* would fail because it exists, but if you add --force, it overwrites it. But honestly, I just added it because it was in the spec and I was hoping you had a scenario in mind :D
There was a problem hiding this comment.
That makes sense. I guess I thought about it some time ago and now my memory does not serve me well.
There was a problem hiding this comment.
Even more curious - should --force be added to the list of generic arguments (like --wait and --verbose-logs)? In the worst case, it doesn't change the behavior, and in most cases it will remove a few lines of code.
| Argument::ForType(Args::Type::Exact), | ||
| Argument::ForType(Args::Type::CustomHeader), | ||
| Argument::ForType(Args::Type::AcceptSourceAgreements), | ||
| Argument::ForType(Args::Type::Force), |
There was a problem hiding this comment.
Also curious what is the scenario for --force in pin remove here?
There was a problem hiding this comment.
I don't know, I added it because it was in the spec. I can remove it until/unless we have a use for it. The only idea that comes to mind is having the command work for single pins and needing --force if multiple pins match.
This change adds an empty
pincommand. Actual implementation of the command will come as a separate PR. This change includes:pincommand and its sub-commandsadd,remove,list,reset. These definitions contain only the definition of arguments but are missing the actual execution code.source lsalias for thesource listcommand.Microsoft Reviewers: Open in CodeFlow