Uninstall an installed App

[denelon]

As a user I want to be able to use winget to uninstall a package so I don't have to go through the Add/Remove software UX.

Experimental Feature winget uninstall <package> - uninstalls the specified package. winget uninstall -? - displays help for the uninstall command.

Note: uninstall depends on list also being enabled.

winget features - displays all experimental features and their status winget settings - launches settings.json to configure settings like experimental features

Note: There are limitations about how programs get installed and whether or not that binary supports uninstall. This may also need to be supported in the manifest with new key(s) and or syntax.

Edited: experimental status

[phiresky]

This is never going to happen since packages just consist of running random executable files that can do whatever they want. There's no package building step or anything.

(edit: see also my clarification below)

[jedieaston]

Chocolatey (and scoop in certain scenarios) already does it through running the uninstaller that is registered in the control panel, I thought. winget could do a similar thing, although the flags for a silent uninstall would have to be in the manifest somewhere.

[michaelvolz]

IMHO this is basic functionality which is paramount for the success of winget.

[Smart123s]

This is never going to happen since packages just consist of running random executable files that can do whatever they want. There's no package building step or anything.

There could be references to the programs' "uninstaller" executables as well. For example, it could launch C:\Program Files (x86)\Steam\uninstall.exe to uninstall Steam.

[Karl-WE]

The uninstaller reference comes with every installation. There are RARE cases of applications that cannot be uninstalled this way but it is doubtful they will be ever accessible / installable via winget.

Other than that you can clearly uninstall all apps using a WMI call and I have even borrowed a method someone else that is even able to crawl the registry for uninstalling applications by a name or wildcards.

Without blaming anyone, I certainly support an /u --uninstall switch, which can also be combined with /h --silent

[Karl-WE]

in terms of naming i would not use Winget remove, imho as it is "install" it should be named "uninstall" for ease of use. https://github.com/microsoft/winget-cli/issues/192

[masx200]

i support it

[phiresky]

For clarification about what I meant with my (admittedly flippant) comment above, see these three threads:

• https://github.com/microsoft/winget-cli/issues/223
• https://news.ycombinator.com/item?id=23238051
• https://www.reddit.com/r/programming/comments/gmqv6n/microsoft_announces_the_windows_package_manager/fr5pasi/?context=3

Basically, my point is that since this works by running arbitrary exe files on the host computer, the only thing it can do to uninstall something is run another arbitrary exe, again pulled from 3rd party sources. That exe can do anything, especially not clean up all the crap left by the install process.

What you expect from package managers (coming from other OSs) is that they build packages that are pretty much just declarative file archives with as little logic as possible, then those are installed with logic defined almost completely on the side of the package manager instead of the to-be-installed app. The logic that comes with the package itself is minimal if it exists at all, runs at specific times with specific functions (preinstall / postinstall / etc) and is declared as readable code (e.g. shell scripts). The package manager or user then can also verify that the package does not do anything weird like copying files to unusual locations or removing other files, or setting up / starting system services. (that's also a job of the package manager).

[Karl-WE]

Yes in fact what you are describing is something like MSI or MSIX / Windows Store that allows an internal uninstall via WinGet while at the moment and forseeable future winget is just the commandline (now also GUI) proxy for this task, but relies on some of the mentioned packagers and installation methods.

[Mallchad]

I don't understand, if one of the intents of this program is to let allow you to install pre-existing software as well as any packages it may have. Is it not possible to run an installer in a kind of sandbox and track installed files? Projects such as Nix, GNU Stow and Arch packages ect ect have worked hard to provide similar functionality with streamlines the proccess with the only difference being that almost always programs are explicitly made to interface with this proccess. Would it not be possible to achieve similar funcitonality with this? There might be some issues with cleaning up files after the installation proccess, but this is a problem that no package manager (that I know of) has solved, and a package manager like this in it's early development could look to solve it, especially since it is official some of this functionality could be facilitated with the kernel.

[Caltor]

This is basic functionality for a package manager really. Without that we have something that is just barely above a powershell script or even a good ol' batch file.

[KevinLaMS]

I have an early draft started of the spec. I am not tackling the notion of a sandbox at this time.

397

[sredna]

SystemAppId is not enough to provide a proper uninstall experience IMHO.

There might be a need for a UninstallSwitches section with at least a Silent entry in the manifest. Unless we want to assume that all uninstallers support the same silent switch as its installer?

It would also be nice if winget tried the de facto standard QuietUninstallString registry value (if it exists) before using UninstallString.

When it comes to actually running the uninstaller, it is a good idea for winget to use a Job object on the uninstaller process so it can wait for all the children like Add/Remove programs does.

If you don't want to use a job object but still want to wait for the process then custom actions are required. For nullsoft this means using its special uninstaller syntax. In a batch file that would look something like this:

@echo off
REM This is a ugly mess because it is very hard for a running .exe to delete itself on Windows.
set "installdir=c:\program files\foo"
set "uninstbin=%installdir%\uninstaller.exe"
call "%uninstbin%" /S _?=%installdir%
if errorlevel 1 goto failed
del "%uninstbin%"
rd "%installdir%"
:failed

[BrainSlugs83]

This is never going to happen since packages just consist of running random executable files that can do whatever they want. There's no package building step or anything.

That's just silly. -- If the package registry can specify an executable which can be run to install a given package, then it should be able to specify an executable that can be run to uninstall a package.

BTW, upon doing a quick search, it looks like package manifests are just yaml files -- so someone does have to build them -- apps don't just automatically have yaml files for no reason. (Not to mention there's a PowerShell script on that page that helps develops build their package manifests...)

And if you can put an "Installers" key in your yaml file, you can sure as heck add an "Uninstallers" key with the exact same info. 😑

[DiegoMagdaleno]

I agree with @BrainSlugs83 you can have contributors declare an uninstall key, that the program just executes, just like Homebrew formulae does, so you can have "if the user wants to uninstall do this: blah blah blah" and it would work without issues imo.

[JanPokorny]

@sredna I understand your point of view. In fact, the approach you are suggesting -- giving the package manager real control over what installs where, as opposed to simply running an exe that pinky-promises to do so -- has already been tried. Scoop package manager is designed to work this way, and in fact most of its large catalog consists of "true" packages -- that is, Scoop just downloads and unpacks app files to a specific folder, without any arbitrary binary running. (...until you run the program that is...) Scoop achieves this by a collection of tricks and hacks, including specialized tools to unpack installers and creating symlinks for persistent files. I like this approach a lot, but it can be limiting for "real-world" applications -- although this works perfectly for Python, there is no way you could install Steam the "Scoop way". Also, this means that manifests for Scoop apps can get much more complicated than WinGet manifests.

I personally think that WinGet should support both types of installation -- prefer "real packages" where possible, otherwise revert to dumb "run exe". In fact, that's what WinGet does now -- MSIX is a "real package" format, and it can even be created for 3rd party apps. This means that any package on WinGet can be a "real package" if MSIX version is added. What remains is to automatically generate and host the MSIX packages somewhere, which I'm sure Microsoft is planning to do.

[zQueal]

Microsoft: This is literally impossible.

Scoop / Chocolatey / AppGet: We've been doing this for 3 years....

Man this company is such a joke, without even the courtesy of a punchline.

[jthoward64]

Microsoft: This is literally impossible. Scoop / Chocolatey / AppGet: We've been doing this for 3 years....

Man this company is such a joke, without even the courtesy of a punchline.

Let's try and keep this issue productive

[Mallchad]

I've had some time to think about the issue as as a broad, universal issue, not specific to winget, and learned a bit more since I last made a suggestion about this, I think I didn't explain myself that well.

I see now we have a basic uninstall capability similar to what you can do in windows uninstaller and that's great, now we're basically dealing with more edge cases and backwards compatibility. Because of course the reason why other some package managers work so well is they are built from the ground up for a specific package format and everybody builds packages for them from the get go, chocolatey and scoop does this to a lesser degree but this isn't really efficient time wise considering the sheer number of apps to deal with, so we need comparability with existing apps, we're part of the way there already.

So how to deal with the problem of cleaning up some of the bulkier files that the uninstaller doesn't deal with, there's kind of 2 solutions as a broad overview, these are both different versions of the same concept.

One of the basic and simplest way to deal with package is just keep a list of files and install these files and remove them again before managing the package, removing or updating, or in some cases writing over the top. In many cases this "list" is actually a file archive that just drops everything from the archive into the filesystem without much care for the outcome, as long as the package manager checks for existing file conflicts or resolves them with something like an atomic Nix store. This works fine but there is 1 major flaw. It's immutable, and file that is added or removed between the installer and the uninstaller, and isn't explicitly picker up by the uninstall process is left behind, cruft.

My proposed solution that could be worked on, that I didn't explain well was basically intercepting files being written by a process so they can be tracked, and eventually removed. Now this has all manners of problems, like extra executable that can't reasonably be monitored, having to actively monitor a process for writes or intercepting such calls at the Windows kernel level, maybe outside the scope of this project? Somebody let me know. Another problem is the files being removed that are necessary for other installed packages for whatever reason, edge cases, this could be improved with kind of atomic actions that doesn't remove things completely from the system immediately and the user or the package manager could determine how much of a good idea that way but that's a lot of extra work.

Basic idea is good in my opinion, what I meant by the sandbox is either creating a sandbox, or some similar process that forces processes from binaries that reside within the package to write within a specific, clean, directory where changes can be listed and tracked for the uninstall process, the only thing to be mindful with the above solutions is not deleting personal files immediately.

This system could be extended to create a "package" when you install said "arbitrary executable" from the internet, simplifies the removal process and helps let the user know where to find files or whatever other information the user ones.

As I mentioned before no other package manager has really solved this problem before, that I know of, and I think it would be quite unique and an achievement to solve a problem like this.

Hope that makes sense.

[JanPokorny]

@Mallchad Your proposal sounds very similar to what MSIX already is/does: https://docs.microsoft.com/en-us/windows/msix/overview

Also,

chocolatey and scoop does this to a lesser degree but this isn't really efficient time wise considering the sheer number of apps to deal with

Scoop is the smaller of the two, with only a few hobbyists backing it, and furthermore it has a much more restrictive "package format" than the other ones, sometimes requiring custom PowerShell scripts for manifests to work properly. Despite that, it rarely disappoints me when searching for packages. If a hobby open-source project can manage, Microsoft can manage.

I believe that the root of this issue is actually Microsoft needing to decide the correct direction for winget to go. And I hope that they get the direction right.

[Mallchad]

I actually wasn't aware this existed and this is what MSIX does... If it works how I think then half the work is already done right? If it fairly quickly creates a package from an installer then you couldjust provide a helper script accessible through the CLI utility can create and install packages from a url right? That wouldn't be too much of an ask or work.

Then you could look into other problems like tracking cruft.

I hope they get the directory right, some of the recent projects have had a very topsy turvy development and direction and for the first time in a while I think winget and WSL is a very strong foot forward, even if it doesn't live up to expectations, it just needs to work.

I''ve got some stuff to tie up but I'll look into experimenting with MSIX and winget at some point.

[jthoward64]

My proposed solution that could be worked on, that I didn't explain well was basically intercepting files being written by a process so they can be tracked, and eventually removed. Now this has all manners of problems, like extra executable that can't reasonably be monitored, having to actively monitor a process for writes or intercepting such calls at the Windows kernel level, maybe outside the scope of this project?

Another problem with this is editor style apps that should leave files behind, or when an app requires uninstallation to update and should keep config files, etc. Additionally this kind of tracking could pose a problem with certain filesystems. The number of issues that could conceivably arise (plus the overhead) would lead me to say that this solution might not be the best. I like a lot of the other ideas you present here though, definitely something to explore.

My proposed solution that could be worked on, that I didn't explain well was basically intercepting files being written by a process so they can be tracked, and eventually removed.

Yeah if the development community switched fully to msix a lot of (un)install problems could be alleviated. Unfortunately there are a few more steps to MSIX than with either MSI (Wix toolkit) and EXE (inno). Plus I think EXE has a bit more capability. Of course the primary barrier to MSIX for smaller software is still the difficulty of acquiring a code signing certificate.

[Mallchad]

Hm, a lot of stuff to consider with getting adoption of compatible formats like MSIX, probably adoption is the most important thing for this project, getting a code signing certificate is....

I don't think that will fly as a blanket solution, but many other projects support user curated packages in one way or another, just I'm just wondering if MSIX can, or could still be used on a trust basis... Need to find out more before I can comment much more on that front.

Didn't consider things like editor style apps, that is a problem... I guess, the least bad solution off the top of my head is to simply track the changes and leave it up to user descrecian what to remove. For consistent, easy to work with and package apps I would guess that 99% of the cruft could be manually compiled into a list of stuff to remove, and stuff to leave.

I was considering the overhead for such a thing like tracking writes, I was thinking about how it could be done say, if I add functionality to facilitate to the Linux kernel, if we had that level of access I don't see why there would be much overhead, you just need add some implementation to the filesystem call and take note of who made the call, assuming such a thing is recorded somewhere. That's kind of a, let's ask Microsoft and see what happens thing though, I think... Not aware of the all of the APIs available. Doing that is userspace is a lot harder, unless you have access to the location, which is why I thought some kind of lightweight sandboxes is a hacky alternative. Need to do more research on this before I say any more.

[denelon]

Building an MSIX does have it's barriers and limitations. It does, however, provide some of the best end user behavior/experience in terms of silent install and uninstall (as well as the fact that in general they clean up better and help to avoid "win rot"). Take a look at the Azure Code Signing service for some investments being made to make code signing easier.

[JanPokorny]

@dandelon I would love to see a repository of MSIX packages built from 3rd party apps. Similarly to what Scoop does -- have a declarative definition of where to download the software, how to check for the latest version, how to unpack the installer, what shortcuts to create etc. --- but instead of performing the steps client-side, they are executed in a CI/CD pipeline and the result is a MSIX package ready to download and install. Would this be doable, at least for open-source apps (since the license may prohibit this)?

[denelon]

@JanPokorny it would be possible to create a third party source (as soon as the REST #118 implementation is complete) that has MSIX packages exclusively.

We've also been discussing a way to filter by installer type. A few customers have suggested filtering by MSIX #304.

There are certainly some examples of how to convert or build MSIX installers so it could be possible to build a pipeline that takes packages and wraps them up in an MSIX. Your concerns about distribution are valid. It seems that a best practice could be to reach out to those open source projects that one cares about and help them to build MSIX output in their CI/CD pipelines targeting distribution via MSIX.

[JanPokorny]

@danelon Thanks for the reply. I was thinking that building a repository of MSIX installers would be a great way to address winget's missing features regarding uninstallation/updating. However, I suppose this won't be possible without a way of packaging 3rd party apps to gain traction for the project -- even for established package managers like Chocolatey, there are very few software developers who actually maintain the package themselves.

[jantari]

It seems like you are discussing my third proposed solution from #407 - provide automatic MSIX re-packaging workflows for all repository submissions in EXE format.

I stand by my points and suggestions from #407. Please make this an actual package manager with true packages and true, reliable uninstalls. As you have discussed here, custom install/uninstall PowerShell wrappers are:

1. A lot of ongoing work/maintenance burden
2. Not provably correct (may miss things or fail)
3. Already done by Chocolatey

EDIT: To summarize, I think only MSI and MSIX should be allowed. EXE Setups can be submitted but they are force-repackaged into MSIX and only approved when the re-packaging was successful. This literally covers all possible usecases and keeps winget "sane and functional":

1. The goal is to deliver most apps as MSIX natively, these obviously work well
2. For scenarios that MSIX does not support yet such as software that doesn't work in the sandbox or that has to install services, we use traditional MSI

The only packages that will be truly unsupported and "left out" are software that:

1. Only ships as an EXE installer
2. Is not compatible with the MSIX Re-packaging tool

And frankly, software that meets both criteria is somewhat dubious to begin with - perhaps it shouldn't be supported, at least not in v1 of winget.

[jedieaston]

The problem is that there’s tons of popular software that isn’t happy being inside a MSIX, like Steam, or Visual Studio. Apps that need (for whatever reason) to be able to spew files/dependencies all over the system, or have lots of installer options aren’t yet a good fit. I don’t doubt that developers should spend some time thinking about this issue (please! MSI has existed since 1999 and it acts right most of the time), but the entire reason exe support exists at all is because migrating to MSIX is a non-trivial operation for a ton of apps.

(Of course, I’d argue half the reason for it being non-trivial is the signature requirements making distributing repackaged apps difficult, but that’s just my perspective from messing around with it outside of a team building a Windows app.)

[jthoward64]

The problem is that there’s tons of popular software that isn’t happy being inside a MSIX, like Steam, or Visual Studio. Apps that need (for whatever reason) to be able to spew files/dependencies all over the system, or have lots of installer options aren’t yet a good fit. I don’t doubt that developers should spend some time thinking about this issue (please! MSI has existed since 1999 and it acts right most of the time), but the entire reason exe support exists at all is because migrating to MSIX is a non-trivial operation for a ton of apps.

(Of course, I’d argue half the reason for it being non-trivial is the signature requirements making distributing repackaged apps difficult, but that’s just my perspective from messing around with it outside of a team building a Windows app.)

While I absolutely agree with every single thing you just said (hence my 👍), there is the point to be made about silent installations not working with most EXEs. But honestly if I were the winget team I would just go ahead and allow EXEs but throw a warning when they are installed/added to the repository and disable silent installs and throw an error when someone tries them. If the problem can be addressed, then it can be addressed down the road, for now EXE support should absolutely be included with winget.

[jedieaston]

Most every EXE currently in the repo is capable of silent installs (there's a couple outliers where the developer broke silent installs in an update, and there's a discussion about interactive-only installs in microsoft/winget-pkgs that I've been meaning to write something on), so I don't think that's a good solution either.

I think the only possible solution is to keep extending MSIX until it can deal with apps that are as complex as Visual Studio/SQL Server/[insert complex app]. If there's a hundred edge cases, no developer will want to deal with it, and since Microsoft doesn't seem to want third-parties repackaging (that makes things like copyright hard, whereas winget just pulling installers the same way a browser does doesn't), I don't know how else to get widespread adoption. Blocking exe files will just mean winget is missing 50% (if not more) of the Windows software catalog, it won't make devs prioritize modern installers.

[jantari]

I must ask, if you insist on EXE support, why don't you just use chocolatey?

Chocolatey has tried very hard, and put a ton of scaffolding in place to try its best to wrangle EXE setups into submission, and to make them behave package-like with wrapper scripts and lots of work that has to be done by the package maintainers.

It would be silly to duplicate all this effort in winget to me.

I know MSIX cannot be used by every application yet. That's why the traditional MSI still exists as well. MSI can handle every type of application so there's no technical limitation - just laziness from some companies who do not want to publish MSI installers.

In my opinion, winget trying to support EXEs like packages (which they ARE NOT) will just mean we:

1. Duplicate all the work chocolatey maintainers did / still do
2. Take away a reason for app developers to finally release MSI or MSIX packages (if EXE is "supported" by winget why would they bother changing to MSI/X?)
3. Will continually run into issues with EXE installers not being removed properly, stealing focus, showing error windows, leaving behind services etc. etc.

I understand some of you just want to type winget install <favoriteSoftware> and have it done without thinking about it, but if you really feel like you must install Steam this way then just use chocolatey. winget needs a differentiating factor anyway, it's the new tool on the block and the underdog - what is its differentiating factor? Well, imo, it should be that chocolatey is just a glorified EXE runner and winget could be an ACTUAL package manager - less software selection, sure, but only real and honest packages with perfect silent installs and removals and perfect ability to keep track of versions and dependencies. None of that will ever be possible with EXEs.

I don't see any value in recreating chocolatey, which already exists if you want it.

winget should be different, and better in some ways. Let's make it better by only supporting MSI and MSIX, and with that: perfect uninstalls. Since this is an official Microsoft tool that will even ship included in Windows, this will (once it ships in Non-Insider builds) further promote the use of MSI and MSIX and the software selection will improve naturally as people start using winget and request more and more packages/software be released as MSI/X - and if you feel like you cannot wait for that then just use chocolatey today.

Not trying to argue, this is really quite cut and dry to me. I only see downsides and problems with supporting EXE and absolutely no benefit. Especially think about the point that supporting EXEs is not only bad, it also means there is absolutely no incentive for companies and developers to adopt/switch to MSI or MSIX which hurts the entire Windows platform in the long run, that would really be quite a severe and long-term consequence!

We either fix windows software installs with winget together, today, or we stay in the dark ages of shoddy, problematic software handling on Windows until Microsoft eventually tries again in 25 years with winget2, or msget or whatever they'll call it. Why would we consciously choose that?

[jedieaston]

Chocolatey executes arbitrary PowerShell scripts and wants admin rights as opposed to winget only allowing a manifest to pass specific command-line flags, that's enough for me to not want to use it.

Take away a reason for app developers to finally release MSI or MSIX packages (if EXE is "supported" by winget why would they bother changing to MSI/X?)

I don't think a CLI package manager, even if Microsoft backed, will convince companies to invest in decent installer infrastructure where 20+ years of SCCM and it's brethren couldn't (not to mention GPO software installs, Chocolatey, NuGet, PDQ Deploy...). It's clear they need a turnkey-ish solution to be interested (or for Microsoft to say that arbitrary exes will no longer be allowed to write outside of user directories, but the chances of that happening are slim to none).

It's unfortunate, it really is, but for adoption, you either need to support EXEs and all of their warts, or begin a mass effort from Microsoft to the software vendors to plead them to either adopt MSIX or explain why they can't so it can be improved.

(Or, I suppose, Microsoft could allow the community to send in build scripts for turning EXEs into MSIXs in winget manifests, and they could repackage and sign, and then host those files for the users so when they run winget install they receive the repackaged MSIX. As I mentioned before though, I think they may run afoul of some copyright stuff with this. It would allow us to crowdsource what applications can't currently be packaged as MSIXs though, which could be useful).

[jthoward64]

I must ask, if you insist on EXE support, why don't you just use chocolatey?

Chocolatey has tried very hard, and put a ton of scaffolding in place to try its best to wrangle EXE setups into submission, and to make them behave package-like with wrapper scripts and lots of work that has to be done by the package maintainers.

It would be silly to duplicate all this effort in winget to me.

I know MSIX cannot be used by every application yet. That's why the traditional MSI still exists as well. MSI can handle every type of application so there's no technical limitation - just laziness from some companies who do not want to publish MSI installers.

In my opinion, winget trying to support EXEs like packages (which they ARE NOT) will just mean we:

1. Duplicate all the work chocolatey maintainers did / still do

2. Take away a reason for app developers to finally release MSI or MSIX packages (if EXE is "supported" by winget why would they bother changing to MSI/X?)

3. Will continually run into issues with EXE installers not being removed properly, stealing focus, showing error windows, leaving behind services etc. etc.

I understand some of you just want to type winget install <favoriteSoftware> and have it done without thinking about it, but if you really feel like you must install Steam this way then just use chocolatey. winget needs a differentiating factor anyway, it's the new tool on the block and the underdog - what is its differentiating factor? Well, imo, it should be that chocolatey is just a glorified EXE runner and winget could be an ACTUAL package manager - less software selection, sure, but only real and honest packages with perfect silent installs and removals and perfect ability to keep track of versions and dependencies. None of that will ever be possible with EXEs.

I don't see any value in recreating chocolatey, which already exists if you want it.

winget should be different, and better in some ways. Let's make it better by only supporting MSI and MSIX. Since this is an official Microsoft tool that will even ship included in Windows, this will (once it ships in Non-Insider builds) further promote the use of MSI and MSIX and the software selection will improve naturally as people start using winget and request more and more packages/software be released as MSI/X - and if you feel like you cannot wait for that then just use chocolatey today.

Not trying to argue, this is really quite cut and dry to me. I only see downsides and problems with supporting EXE and absolutely no benefit. Especially think about the point that supporting EXEs is not only bad, it also means there is absolutely no incentive for companies and developers to adopt/switch to MSI or MSIX which hurts the entire Windows platform in the long run, that would really be quite a severe and long-term consequence!

We either fix windows software installs with winget together, today, or we stay in the dark ages of shoddy, problematic software handling on Windows until Microsoft eventually tries again in 25 years with winget2, or msget or whatever they'll call it. Why would we consciously choose that?

You make some good points here but "why not use Chocolatey" is like responding to a bug in notepad by saying why not use Sublime Text? Because if Microsoft is gonna release a product it should be a good and well rounded one.

[jantari]

Chocolatey executes arbitrary PowerShell scripts

Which it doesn't do because it wants to. It does it this way because it needs the custom scripts to work around the problems of the EXE installers it supports.

and wants admin rights

winget needs admin rights too to install software machine-wide, especially EXEs. Funnily enough, there is actually an option in Windows to allow a non-admin to install MSI-packages machine-wide without administrator rights (the "Always install with elevated privileges" group policy in case you're curious - I know it's terrible security, but my point is MSI allows for this at all), but with EXEs this is not possible at all and winget cannot work around this unless they want to run a permanently elevated background service (which it currently does not do, which is why it UAC prompts you to run software installers) - yet another disadvantage of EXEs

as opposed to winget only allowing a manifest to pass specific command-line flags

Manifests are cool, but not enough to support EXEs. Notice how winget can get by with just a manifest today, but it is in very early alpha and its features and exact scope are still heavily discussed. Also note how chocolatey has been out for many many years and has a somewhat well-defined goal and approach, and wide software support - and it uses PowerShell wrapper scripts. That's not a coincidence. In order to support all the problematic EXE installers out there, you need a lot of flexibility and possible options and capabilities in your installation process (create files, remove files, create registry keys, delete registry keys, check for pending reboots, set environment variables etc. etc.) and that means you either go the chocolatey route and give package maintainers full cretive freedom with custom PowerShell scripts, or you completely blow the manifest spec out of proportion by supporting every possible thing an EXE might need or want done prior and after its execution to run as expected, and cleanly aka without residual files or registry entries.

Which problem do you choose?

I say neither. I don't want arbitrary PowerShell scripts run as admin on my system and I don't want an overblown, overcomplicated manifest format that will need to be supported, maintained, backwards-compatible and bug-tested for every niche scenario by the poor winget developers.

Instead, imagine if we just use MSI and MSIX. No PowerShell scripts needed. Manifest format could be dead-simple and still work/support all packages. All software could be installed with or without admin-rights, guaranteed. No special snowflakes, no surprises.

I know not all EXE installers are equally bad. Some of them are almost as good as MSI packages, sure. But because you cannot know that just by inspecting the setup file from the outside, winget knows nothing when it runs the EXE - aside from what the manifest theoretically promises. But what about EXE setups that bundle a dependency like Microsoft Visual C++ Redist 2017 - how do you teach winget about the fact that installing this will also install another software? How would you subsequently uninstall or update that dependency-software with winget? The only way is through the manifest, make the manifest more complicated to indicate bundled dependencies and their full package specifications. Then the software auto-updates itself and winget cannot know that if it's an EXE because there's no central database of version numbers for installed EXE software, unlike MSIs. When an MSI software is updated outside of winget, winget notices that and can correctly show it as up-to-date. How do you fix this for EXEs? In the manifest? You can't. You could only fix it by disallowing EXE installers.

See, chocolatey uses PowerShell scripts and their flexibility for a reason. That reason is, they chose to go the route of allowing EXE installers - and now you yourself say, ugh, that's messy and I don't want it. But winget is headed for the same fate.

[jedieaston]

You have some good points, and I'd be convinced if I could see a path to getting software vendors on board....

Then the software auto-updates itself and winget cannot know that if it's an EXE because there's no central database of version numbers for installed EXE software, unlike MSIs. When an MSI software is updated outside of winget, winget notices that and can correctly show it as up-to-date. How do you fix this for EXEs? In the manifest? You can't. You could only fix it by disallowing EXE installers.

Add/Remove Programs functions as this for EXE installers, and winget will eventually have support for adding standalone (non-installer) apps to it. Whether that encourages lazy app development is up to the reader.

[Mallchad]

The only problem, and I mean the only problme, I see with ignoring excutables, is adoption... It would be quite difficult to get developres to adopt the package manager for a while... And until then Winget has greatly diminsihed usage/use-case, like it does now.

Although I get there is a lot of problems with supporting "legacy" installers and it might be a waste of effort in areas. With this in mind if Winget were to support "legacy" installers, I think the lowest effort (but still effective) solution should be found. Backwards compatability as I'm sure you know is an ongoing problem.

Unless somebody were to propse integration / chocolatey support.

[jedieaston]

Interesting discussion around the pains of MSI: https://news.ycombinator.com/item?id=26846696, if anyone wants context around why we still have the exe installers.

[JanPokorny]

@jedieaston Microsoft is now in a great position to make MSIX better (drop signature requirement, add direct support to common setup wizard frameworks to make adoption easier, ...) and push it using winget ("you can put your app on winget, just use this installation format your pipeline probably already supports"). Once winget is included in Windows, developers might even use it to auto-update their apps basically for free. I don't think there's a high chance of this happening, but it would surely be great.

[keenbowl3009]

@jedieaston Microsoft is now in a great position to make MSIX better (drop signature requirement, add direct support to common setup wizard frameworks to make adoption easier, ...) and push it using winget ("you can put your app on winget, just use this installation format your pipeline probably already supports"). Once winget is included in Windows, developers might even use it to auto-update their apps basically for free. I don't think there's a high chance of this happening, but it would surely be great.

The MSIX format is really horrendous because it allows the insertion of DRM in software through the form of the AppxBlockMap.xml files.

On top of that, it is only supported on windows. It is really the most horrible and frustrating one of the choices.

Really really awful that microsoft is attempting to push forward with the locking of windows, without fixing any of the underlying problems of the platform.

[JanPokorny]

@keenbowl3009 Most paid software already has DRM, with or without MSIX.

Also, how is "it is only supported on Windows" an argument? Scoop is only supported on Windows, Homebrew is only supported on Mac and Apt is only supported on Linux, does that make them bad?

[keenbowl3009]

scoop is a shell script that unzip files, and adds to path.

can you unzip files, and add them to path with winget?

[keenbowl3009]

https://devblogs.microsoft.com/commandline/windows-package-manager-preview/

You are going to be able to winget install your way to bliss. One of the best parts is that it is open source. I had to pinch myself when I was able to winget install terminal, and then winget install powershell, and then winget install powertoys.

Can you winget install any of those from the original winget annoucement?

[JanPokorny]

scoop is a shell script that unzip files, and adds to path. can you unzip files, and add them to path with winget?

No, it's on the roadmap, and I don't get how it's related to the previous conversation.

Can you winget install any of those from the original winget annoucement?

All of them! In fact I installed all of these through winget. What are you even trying to say?

[jthoward64]

Given that

A. You don't like winget B. You like scoop

I suggest that you

Use scoop

EDIT: also could a mod mark everything for the last hour as off topic please? @denelon

[Masamune3210]

Yet another bad faith argument, seems people love these lately

[denelon]

@tajetaje Since this issue is closed, I don't see much value in marking the thread "off topic". Unfortunately, there probably isn't a single solution that will make everybody happy. Sometimes people want to make sure they are heard. There are several tools attempting to solve the problems related to managing software on Windows. We're not trying to replace any of them. We're trying to meet developers where they are and have a plan to go forward in time. Some of the constraints we're trying to adhere to make the problems more challenging in some areas and easier in others. Hopefully over time, we will build something that is flexible enough to give the control users want and the flexibility to work with existing installers.

[JanPokorny]

@denelon > We're not trying to replace any of them.

I'd be... more cautious with that statement. https://keivan.io/the-day-appget-died/

[keenbowl3009]

scoop is a shell script that unzip files, and adds to path. can you unzip files, and add them to path with winget?

No, it's on the roadmap, and I don't get how it's related to the previous conversation.

Can you winget install any of those from the original winget annoucement?

All of them! In fact I installed all of these through winget. What are you even trying to say?

winget install powershell will literally give me an error.

On top of that, i'm afraid of even running that and permanently borking my machine.

[Masamune3210]

If you are getting a error installing something, open a ticket. Things can't get fixed if the devs don't know of the issue