Draft of List, Upgrade and Uninstall.

[KevinLaMS]

This includes issue 120, 121 and 119.

Microsoft Reviewers: Open in CodeFlow

[megamorf]

What about paid apps that have been purchased already?

[yao-msft]

If the entitlement is already granted, I think we can continue with installation.

[megamorf]

@KevinLaMS Some general feedback.

Based on the contents on these drafts you haven't worked with Markdown that much so here are some potential issues that can be solved fairly quickly:

• When using inline or fenced code formatting you don't need to escape characters (e.g. angle brackets) with a backslash `winget list [[-q] <query>] [<options>]`
• Instead of using HTML tags for formatting try to stick with the markdown versions, e.g. **bold string** instead of <b>bold string</b>
• All path references in markdown use a regular slash as path separator
• lists, headings and tables should be surrounded by new lines

See: https://www.markdownguide.org/basic-syntax/

I like where this is going and will add more feedback later. 👍

[fmeyertoens]

Just a few typos.

[martinmine]

Some comments from the discussion in #120

[martinmine]

Small typo:

Suggested change

	For our preview of the Windows Package Manager, the goal was to enable install of apps. In order to be a package manager, the Windows Package Manager must be able to list all installed packages, communicate if there is an update ane uninstall apps.
	For our preview of the Windows Package Manager, the goal was to enable install of apps. In order to be a package manager, the Windows Package Manager must be able to list all installed packages, communicate if there is an update and uninstall apps.

[martinmine]

Another aspect to consider: What would happen if the user updates an app that is not installed? Should it then display an error or install said app?

[martinmine]

Should winget exit with a non-successful status code if this is the case?

[JohnMcPMS]

Yes, I believe so. If the command requested cannot be executed, the process should return a failure exit code.

[rmarquis]

This seems counter intuitive to me, and it's also not what Linux package managers do as far as I know (using pacman here). If the purpose of the upgrade command is to check if newer version of package(s) are available and get them, then it didn't fail if the last available package(s) are installed already. The output should be different (f.e. "there is nothing to do") but the command would be considered a success anyway.

[JohnMcPMS]

I guess it comes down to what the purpose is deemed to be semantically. I am not opposed to the purpose being "Make sure I have the latest version of this", which then I agree with you that no error is correct. I was reading it more as "Get a newer version of this", which while I agree is a subtle difference, it is still the difference between a command that cannot be executed, versus one that can.

I suppose there is the question of what is done in the --all case. In that case, should there be an error if no updates are available for anything? That feels wrong to me, as I don't think anyone would ever say "Get a newer version of everything". So for consistency, I believe that the semantics should be Ensure, not Get.

So I agree that there should not be an error exit code, and the verbage here should be "issue a warning" not an error.

[martinmine]

A suggestion for what could be discussed here: The impact on users that have not used a package manager, will they naturally use update instead of upgrade (or sometimes have issues with distinguishing these two)? And on the other hand, if update was an alias for upgrade, how can similar functionality of upgrade be used with the alias and vice versa? (For example: #120 (comment)) It would be really nice to see what is the plan for dealing with this kind of complexity (update vs. upgrade) from a user standpoint.

[JohnMcPMS]

I prefer "update'. Upgrade has other semantics (at least to me), and update fits more cleanly into what is happening.

[martinmine]

@JohnMcPMS If you decide to go with update, then I would suggest to make upgrade alias of update to make the life easier for users familiar with other package managers that use upgrade for updating packages.

[RobGThai]

Brew user here, every time I want to update an app, I have to look up help to see if I need to update or upgrade. One is making sure Brew is up to date, the other is for updating the app. If you trigger update without supplying app identifier then Brew will attempt to update every installed packages. Which I'm not a fan of.

Personally, I'm against making alias between update and upgrade. Having just one version of them at the start should reduce confusion on which one to use for newcomers. Instead of doing this, I'd suggest WinGet to only offer just one.

• winget update - displaying help for update.
• winget update <package_id> - updating provided package.
• winget update winget - updating WinGet itself.
• winget update -a|--all - updating every installed packages.

[quangkieu]

I think winget should use keywork like apt of Debian.

• Update: for refresh the catalog
• Upgrade: for actual installation operation of new version

This way we could remove the refresh frequency as winget user does not expect winget run in background as a CLI tool usually run and exit

[martinmine]

Would the user be prompted to confirm the package update? If yes, should there be flag to override this when being used in automation tasks, similar to how other package managers does this?

[megamorf]

Sounds like a good idea to stick to that already established pattern where by default a confirmation is required to proceed that can be skipped by passing an additional parameter.

[martinmine]

What about specifying a manifest file that is located on the user's machine (or another repository)? Would this be part of another spec?

[martinmine]

It would be nice to hear how syncing with the remote repository will be handled, will the user have to do this manually (i.e. using an update), or will it be done automatically if the repository hasn't been synced after a said time?

[KevinLaMS]

Martin, I am curious. I think that the syncing of the remote repository is handled via the source:
C:\Users\kevinla>winget source update
Updating all sources...
Updating source: winget...
██████████████████████████████ 100%
Done.

Do you think this addresses the Update concern?

[martinmine]

It is true you can handle this using the winget source command. I just think the spec should outline how the syncing of the remote repo is handled in context of running an update. Is a user required to run an winget source update before running winget upgrade or will this be implicit from running winget upgrade? (i.e. upgrade will invoke source update)

[megamorf]

In Linux package managers update the package cache for all enabled repositories. If a package was installed from repository "foo" then the search for available updates for that specific application will be narrowed down to repository "foo". If you'd actually want to install a new package that is available in multiple repositories without explicitly providing the correct repository name, the package will be installed from the repository with the highest priority. This priority system is also how the upcoming version 3 of PowerShellGet has been designed to define repository ordering.

[lordcheeto]

As of now, whenever a source (SQLite DB) is opened, it updates the source if it's been more than 5 minutes. winget source update is just the explicit command to update.

// TODO: Enable some amount of user control over this.
constexpr static auto s_DefaultAutoUpdateTime = 5min;

[martinmine]

Handling available updates with this would be similar to how dotnet handles packages updates, nice 👍 https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-list-package

[JohnMcPMS]

Update metadata.

[JohnMcPMS]

Add links to Issues per latest spec template.

[JohnMcPMS]

Do we actually care about differentiating things installed by winget vs things that weren't? Doesn't seem very useful to me.

[JohnMcPMS]

Not relevant.

[JohnMcPMS]

MSIX. Store is potentially a whole other can of worms. And we might have things available via both (Terminal for instance).

[JohnMcPMS]

I prefer "update'. Upgrade has other semantics (at least to me), and update fits more cleanly into what is happening.

[JohnMcPMS]

Yes, I believe so. If the command requested cannot be executed, the process should return a failure exit code.

[yao-msft]

Does uninstall handle apps installed outside of WinGet?
If there're multiple matches with the query. Should we return a warning message saying "please refine the input ..." like what install command does today?

[dev-nicolaos]

Not a huge deal, but I'd personally prefer the -h alias as it is far more common and more clearly maps to --help than -?

[GauthierPLM]

Isn't -? the standard on Windows while -h is more a Unix thing?

[jsoref]

@KevinLaMS: can you please pull master and then rebase this (start with a temporary branch -- see below)? The spell checker will be upset if this merges as is.

Most of the items it found just need to be added to expect.txt.
Ideally you'd only add words in this manner and you'd use patterns.txt for random strings (I've highlighted some random strings here). But if there's no pattern that works usefully (the random BigId that appears in multiple contexts is a good example), then using expect.txt is a good choice.

Note: you can test on another branch and only force push to this branch once the spell checker is happy.

[jsoref]

Suggested change

	Phase 1 will be kick the tires. The Windows Package Manager will only install apps that meet the following critieria:
	Phase 1 will be kick the tires. The Windows Package Manager will only install apps that meet the following criteria:

[jsoref]

Suggested change

	* **StoreId**: The StoreID is the 12 character number that is used to reference the application in the store. This is a Windows Store ID, often referred to as BigId when interacting with the store team. Example: 9nblggh4nns1.
	* **StoreId**: The StoreID is the 12 character number that is used to reference the application in the store. This is a Windows Store ID, often referred to as **BigId** when interacting with the store team. Example: `9nblggh4nns1`.

[jsoref]

Suggested change

	Example: 9nblggh4nns1
	Example: `9nblggh4nns1`

[jsoref]

Is this an example?

[jsoref]

For this, you'll want to add an entry into patterns.txt,

probably something like:

(?:Signature|)Sha256: "[0-9A-f]{64}"

[florelis]

I assume shellexec means using ShellExecute instead of CreateProcess? Is there a reason for that? ShellExecute requires a file path and arguments so the uninstall string would need to be parsed to split it, whereas CreateProcess can take the command line string directly which seems like a better fit.

[ghost]

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.