search

microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
22.95k stars 1.43k forks source link

The separate names for App Installer and winget create confusion #2421

Open Jawz84 opened 2 years ago

Jawz84 commented 2 years ago

Edit: This issue started out as "winget uninstall microsoft.winget.source_8wekyb3d8bbwe should uninstall winget.exe and let user reinstall from store". And along the way, it was learned that the problem was that the naming of the different components creates confusion, leading to this issue. The new purpose of this issue is: What can we do to make the components necessary for winget cli more coherent in name, or how can we make sure the diferent components are not creating confusion when using winget.

Problem/how to reproduce

When running winget uninstall microsoft.winget.source_8wekyb3d8bbwe, winget.exe is still available for use, even after restarting the terminal. The appx package microsoft.winget.source_8wekyb3d8bbwe is removed (as shown by winget and Get-AppxPackage), but it cannot be installed again, the Store does not show any action buttons for it:

image

I also noticed that winget list now warns that something went wrong:

~> winget.exe list
Failed in attempting to update the source: winget
Failed when searching source; results will not be included: winget
Name                                           Id                                                        Version
--------------------------------------------------------------------------------------------------------------------------
[abbreviated]

Expected behaviour

I would have expected the winget uninstall action to remove winget.exe and the package, and that I would be able to just reinstall the package from the Store.

Attempts at recovery

I tried:

workaround

Go to https://aka.ms/getwinget, and reinstall the package. Can be scripted as: 

Invoke-RestMethod aka.ms/getwinget -outfile winget.msixbundle
Add-AppxPackage .\winget.msixbundle
# (Give it a minute or two to silently install in the background)
 do {Start-Sleep 10; Write-Host -NoNewline '.'} until (winget list | Select-String 'winget.+')

Version

~> winget --version
v1.3.2091
Trenly commented 2 years ago

See #2412 regarding the error when removing the package.

Microsoft.winget.source_8wekyb3d8bbwe is not the package which contains the executable for WinGet. What it actually is, is the data for the default source named ‘winget’ which is from the winget-pkgs repo. By removing the package, you are removing all the data present from the source, but not the WinGet executable.

To uninstall the executable, You will need to remove the Microsoft.DesktopAppInstaller package

Jawz84 commented 2 years ago

Thanks @Trenly, I understand.

Still, for users, this is confusing. There is no way of knowing that DesktopAppInstaller is the actual package for winget

~> winget list appinstaller
Name          Id                                          Version
---------------------------------------------------------------------
App Installer Microsoft.DesktopAppInstaller_8wekyb3d8bbwe 1.18.2091.0

Does not have winget in the name anywhere.

And in the names Microsoft.winget.source_8wekyb3d8bbwe and Windows Package Manager Source (winget) the word 'Source' can be easily overlooked or misinterpreted.

Sidenote: uninstalling the package is not supported with winget it seems:

~> winget uninstall Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
Found App Installer [Microsoft.DesktopAppInstaller_8wekyb3d8bbwe]
Starting package uninstall...
                                  0%
Uninstall failed with exit code: 0x80070032 : De aanvraag wordt niet ondersteund. (unsupported request)

I imagined this is because the winget.exe process being in use blocks it from being removed, but it can't be removed via Store either. (It can be done with Remove-AppxPackage it seems.)

Trenly commented 2 years ago

There is no way of knowing that DesktopAppInstaller is the actual package for winget

When installing through the store, you install "App Installer", not "Winget". I can see where it could be argued both ways, especially since the releases here on GitHub also have the name Microsoft.DesktopAppInstaller_8wekyb3d8bbwe. I can see how it would be confusing though.

denelon commented 2 years ago

We're having some lively discussions internally about the naming and distribution of the Windows Package Manager. I don't expect we will make any changes in the short term as changes would represent a large impact. If / when we come to a decision to change anything, we will certainly communicate well in advance.

This feedback is not taken lightly.

For some additional context, the App Installer handles the UI/UX for installing MSIX packages and is essentially a prerequisite to installing MSIX packages in WinGet. The decision to include WinGet in the App Installer was heavily influenced by that dependency. Pulling WinGet out of the App Installer or renaming App Installer would likely cause several points of confusion and complexity.

Jawz84 commented 2 years ago

Thank you @denelon ! Naming is hard, process is hard, large enterprise decision making is hard. I get it 💙. Thanks for winget, I am a fan.

Anything to improve default availability of winget on new systems is the real big win (#1738), and consistent naming.. Would be great if you can get it done!

denelon commented 2 years ago

Thanks for the support!

"There are only two hard problems in Computer Science: cache invalidation and naming things." We have both problems 🤦‍♂️

We do ship "App Installer" with the OS, but it takes time to get the version updated to one including Windows Package Manager. Those kinds of changes go with the OS schedule. The Microsoft Store has its own built-in mechanisms and time delays for updates after the Out of Box Experience (OOBE), and gradually over time after that. Lots of moving targets with different time horizons. This should consistently get better over time though.

Jawz84 commented 2 years ago

In this light, would you like to keep this issue open and rename it to something about naming, or would you like to close it as dup of #2412? From my perspective, the issue is clear, and knowing both naming and 2412 are on the radar is enough.

denelon commented 2 years ago

I would suggest renaming this one or creating a new one as a Feature related to helping alleviate the ambiguity and confusion of the named packages.

Alternatively, you could start a discussion topic and then link to that in this issue and close it. Either way, history is preserved 😊

Jawz84 commented 2 years ago

I would suggest renaming this one or creating a new one as a Feature related to helping alleviate the ambiguity and confusion of the named packages.

Alternatively, you could start a discussion topic and then link to that in this issue and close it. Either way, history is preserved 😊

I've chosen to rename this issue, and added a note at the top to reflect that and give a little context.

A broader discussion about naming or documenting and or communicating about components may be helpful, but I am not the one to start it at this time. Thanks so far!

Jawz84 commented 2 years ago

@denelon could you have one more look, and maybe change the label?

casperdcl commented 1 year ago 
> Remove-AppxPackage Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe
Remove-AppxPackage : Deployment failed with HRESULT: 0x80073CFA, Removal failed. Please contact your software vendor. (Exception
from HRESULT: 0x80073CFA)
error 0x80070032: AppX Deployment Remove operation on package Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe from:
C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.18.2691.0_x64__8wekyb3d8bbwe failed. This app is part of Windows and
cannot be uninstalled on a per-user basis. An administrator can attempt to remove the app from the computer using Turn Windows
Features on or off. However, it may not be possible to uninstall the app.
halr9000 commented 1 year ago

Just realized that I'm stuck on 1.3 and have the above named source installed (Microsoft.Winget.Source_8wekyb3d8bbwe). After reviewing this issue, it's actually unclear to me. What is the best way to get to the latest/1.4?

denelon commented 1 year ago

Just realized that I'm stuck on 1.3 and have the above named source installed (Microsoft.Winget.Source_8wekyb3d8bbwe). After reviewing this issue, it's actually unclear to me. What is the best way to get to the latest/1.4?

Several methods should work

halr9000 commented 1 year ago

I actually wanted to try out the Windows store but that has noted there are no install or uninstalled buttons for me.

Likewise the app X didn't do anything. I have not yet nuked anything from orbit but that was going to be my next step. Sounds like that's your recommendation?

On Thu, Mar 9, 2023, 12:00 PM denelon @.***> wrote:

Just realized that I'm stuck on 1.3 and have the above named source installed (Microsoft.Winget.Source_8wekyb3d8bbwe). After reviewing this issue, it's actually unclear to me. What is the best way to get to the latest/1.4?

Several methods should work

— Reply to this email directly, view it on GitHub https://github.com/microsoft/winget-cli/issues/2421#issuecomment-1462421224, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEQMVLVDJRM7WIZU3R2HTW3IECHANCNFSM55VQ2NQA . You are receiving this because you commented.Message ID: @.***>

ItzLevvie commented 1 year ago

I actually wanted to try out the Windows store but that has noted there are no install or uninstalled buttons for me.

You can click on the "Get updates" button in Microsoft Store > Library to fetch latest updates.

You can also run winget install --id 9NBLGGH4NNS1 --source msstore --force in Command Prompt or PowerShell.

If that doesn't work then you can manually install the latest build from https://aka.ms/getwinget and double-click on the .msixbundle file and then click on the "Update" button.

halr9000 commented 1 year ago

You can click on the "Get updates" button in Microsoft Store > Library to fetch latest updates.

No, that was noop for me.

You can also run winget install --id 9NBLGGH4NNS1 --source msstore --force in Command Prompt or PowerShell.

Did not see that in time, am curious to know if --force would have done the trick.

If that doesn't work then you can manually install the latest build from https://aka.ms/getwinget and double-click on the .msixbundle file and then click on the "Update" button.

Had tried that as well, made no change in CLI nor GUI.

However, an Add-AppXPackage did the trick as suggested here.

Thanks