-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Added argument to control whether to upgrade packages if they have "unknown" versions #1765
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
Changes from all commits
56f1e9f
892a5e5
eb3d2f0
f80b365
ae9ffc4
061a201
488f810
825dac3
ebd54f9
841e769
6dc0982
2d49a69
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -708,6 +708,7 @@ namespace AppInstaller::CLI::Workflow | |
| }); | ||
|
|
||
| int availableUpgradesCount = 0; | ||
| int unknownPackagesCount = 0; | ||
| auto &source = context.Get<Execution::Data::Source>(); | ||
| bool shouldShowSource = source.IsComposite() && source.GetAvailableSources().size() > 1; | ||
|
|
||
|
|
@@ -720,6 +721,13 @@ namespace AppInstaller::CLI::Workflow | |
| auto latestVersion = match.Package->GetLatestAvailableVersion(); | ||
| bool updateAvailable = match.Package->IsUpdateAvailable(); | ||
|
|
||
| if (m_onlyShowUpgrades && !context.Args.Contains(Execution::Args::Type::IncludeUnknown) && Utility::Version(installedVersion->GetProperty(PackageVersionProperty::Version)).IsUnknown()) | ||
| { | ||
| // We are only showing upgrades, and the user did not request to include packages with unknown versions. | ||
| unknownPackagesCount++; | ||
| continue; | ||
| } | ||
|
|
||
| // The only time we don't want to output a line is when filtering and no update is available. | ||
| if (updateAvailable || !m_onlyShowUpgrades) | ||
| { | ||
|
|
@@ -766,6 +774,10 @@ namespace AppInstaller::CLI::Workflow | |
| context.Reporter.Info() << availableUpgradesCount << ' ' << Resource::String::AvailableUpgrades << std::endl; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see that you are using different strings to report the count depending on whether there is a single package or multiple, but here we were using the same string for both cases. I think we should be doing the same for both messages; although I'm not sure which one would be better. I would lean towards using a single string regardless of the number of packages as I don't know if there are any languages that make any distinction beyond 1/many or that don't make distinctions at all.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I looked a bit into pluralization and it's a whole rabbit hole one can go into. I found it interesting to look at the rules for all languages...
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I saw that too, but figured it was a separate PR... thanks for pointing it out :D
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we wanted to do something to handle plurals programmatically, then we could probably do it at the same time as the dynamic string replacement mentioned above. I don't see it as important as the dynamic strings though, so depending on the complexity we might just leave a nice place for it. I don't know if the english standard of making it "optional" like: applies to the other supported languages. But it might be an option.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should I go ahead and use a optional plural for now?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That sounds good to me. |
||
| } | ||
| } | ||
| if (m_onlyShowUpgrades && unknownPackagesCount > 0 && !context.Args.Contains(Execution::Args::Type::IncludeUnknown)) | ||
| { | ||
| context.Reporter.Info() << unknownPackagesCount << " " << (unknownPackagesCount == 1 ? Resource::String::UpgradeUnknownCountSingle : Resource::String::UpgradeUnknownCount) << std::endl; | ||
| } | ||
|
|
||
| } | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@denelon for argument name review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I find the argument name somewhat awkward for a single app:
winget upgrade SomeApp --include-unknownFor
upgrade --allI understand it as "include apps with unknown version", but I don't quite get what we are "including" for a single app.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if the user explicitly specifies an app,
--include-unknownwould/should be redundant.I also think
winget upgrade AwesomePackage --allwould be similarly strange.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current behavior is that
upgrade <ID>doesn’t upgrade a package if already at latest. I had the argument behavior stay the same so the expectation of winget not doing an upgrade unless it has to holds.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Community opinion here; I would think that if I specify an ID, it should attempt to be upgraded even if the version is unknown. I would think that even if the version doesn't change, from a user perspective, an upgrade was at least attempted. It could be very confusing if the user knows there is an update, and they try to upgrade it only to be told that no applicable update was found.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's also a message that prints:
There was some discussion in the issue about whether or not there should be a setting to restore the current behavior (when in doubt, upgrade), but by default I think it should prompt the user to make a decision. The infinite reupgrading is causing more confusion than this is, IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, I must have missed that. I would be fine with that approach, since it is clear and informative