-
Description of the new feature/enhancementThis is a suggestion / spec / discussion on how I believe This is intended to be an open discussion about #223, @aclinick replied there that the adoption of MSIX This proposal is the formal version of replying "so what?" to this. Let us build the right thing now for the future, instead of reinventing the past we're tring to get away from so desperately What is wrong with supprting .EXE (not a complete list by ANY means):
Proposed technical implementation details (optional)Three options: 1. Slim down the scope of winget-cli and the manifest format.Only allow .MSIX (or .MSIXBUNDLE) application packages, because these are true "OS-manageable" packages in the sense one would expect from a package manager. 2. Only allow .MSIX, .MSIXBUNDLE and "legacy" .MSI.MSI packages aren't perfect, but they are a lot better than the wide variety of .EXE Setup packagers. 3. Only allow .MSIX and .MSIXBUNDLE packages, but provide re-packaging CI for .EXE and .MSIThe MSIX Packaging Tool can execute .EXE and .MSI Setups and repackage them into .MSIX - most of the time. There could be special "winget-repackager"-as-a-Service tool set up by Microsoft (GitHub Actions/Cloud-based) where any .EXE and .MSI packages submitted for winget will be automatically repackaged into .MSIX by the MSIX Packaging Tool under the hood - and when no errors or warnings occurred, the package is good to go and will be added to the repositories. If the Installer tries something that .MSIX does not support yet, such as installing a Windows service, the packager will error out and refuse. This tool could additionally validate that the produces .MSIX file works by deploying it to itself or a fresh VM/Container and seeing whether that succeeds and whether the package installs. |
Beta Was this translation helpful? Give feedback.
Replies: 37 comments 47 replies
-
|
Any soft of package manager really would need to handle .EXE packages if said packer manager is to gain traction. Yes, it is a hard problem, but declining to deal with it is unlikely to be helpful, certainly not in the short term. This is not Field of Dreams. :-) |
Beta Was this translation helpful? Give feedback.
-
|
To gain traction the package manager needs to be a "package manager", and just running random .EXEs with unpredictable results is not what a package manager does. |
Beta Was this translation helpful? Give feedback.
-
I disagree. I think investing the time and effort into trying to support .EXE installers - mind you, this is futile in the end - is much better invested in improving the MSIX Packaging Tool so it can more reliably repackage these Installers into TRUE packages. It's already great, I've used it myself. I repackaged Thunderbird to MSIX no problem the day the tool came out and it's even better now. This is not as big of a problem as you think. This way, winget can deliver value on three fronts:
By supprting .EXE this tool slows down the adoption of MSIX |
Beta Was this translation helpful? Give feedback.
-
|
I've been devoted to this space for 24 years. I love MSI but the industry has totally failed to embrace it and Microsoft has stopped enhancing it. The only way to really solve this is move everyone over to Windows-S and only support MSIX packages. That is never going to happen. I am passionate about MSI and dislike EXE installers but they are never going to go away. Heck people around here don't want to stop there. They want to be able to extract random ZIP files and somehow "install" them. |
Beta Was this translation helpful? Give feedback.
-
|
You can never make quality software by listening to what everyone wants and complains - you instead figure out the real problem behind their complaints, and find a solution for that, then make it real easy to adopt, and then educate people about it.
MacOS solved the problem by bunding all the application files in one standardized container and stuffing it in a known location, that's kind of ok. Other *nix systems have solved that by providing package managers like The packages define e.g.:
Microsoft has tried solving this in some really bad ways, among them the MSIX format - so if you're wondering why MSIX has not taken off, maybe look at the flaws of MSIX and come up with a real solution? The MSIX containers or whatever you call them don't work in Windows 7 (Edit: apparently not true), which is still very widely in use, so people cannot rely on them, that makes them "just another package" to build, which takes extra effort, and does not bring any benefits - so why would I as a vendor bother with it? They get installed in some magically protected folder that blows up if I try to go edit any permissions to see what's up, and e.g. blocks screen capture software from capturing them. This is a very big and unexpected "gotcha". They also apparently mess around with various things in the filesystem and registry and how they're presented to the applications, making it difficult to trace problems, and tweak things to work the way you want them to. I personally always hope people have NOT used MSIX because of all the nonsense they come with. The Microsoft Store on the other hand constantly nags at me to log in, then tries to push me to use the Microsoft login to log into my computer - I'm just trying to install software here, don't push your unrelated nonsense to me ok? It's also constantly complaining to me because I'm in Estonia and I like U.S. English, so my region is set to U.S. - apparently it's real important that this setting is followed, and that the Store can not give me a setting to change it for the Store instead of my entire OS. Similarly there's issues with customizing install location, which causes problems when this same model is used on the Xbox app and now instead of installing a couple of small apps of a few MB each, you're installing tens of GB. Why do you need a centralized repo (or repositories)? To ensure that random developers don't do what random developers do in all too open ecosystems, they release their buggy patch with the same version number as the previous release, and suddenly my "v1.0.0" install blows up on my face, because the package manager for that ecosystem decided that GitHub tags are a reasonable way of accurately determining versions. It's real sad seeing Microsoft pushing these broken not-even-close-to-what-people-wanted non-solutions and then wondering why nobody adopts them. These problems are not that hard to solve, they have been solved to a much more satisfactory degree by many others, and the solutions are not patented and hidden secrets. What Windows needs is a package manager and software repositories without any extra caveats and gotchas, something that does exactly what people expect from a package manager, and that works on the systems users actually have so software vendors can support it. The existing code signing support combined with trustworthy repositories with maybe some automatic security scans, easy way to test it on all different versions of Windows, some clear and easy certification process, a clear storefront without any of the nonsense, and a package manager capable of the fairly commonplace "install these packages", "uninstall those packages", "update all my software", "tell me what I have installed", and "install security updates automatically" -functions would make Windows a much better platform. As a cherry on top, allow users (not Administrators) to install things under their own user account, without modifying the system's protected folders, and you're approaching something decent. If you really want to kick ass with the best of them, make these reproducible and reliable like https://nixos.org and many of us will just stop looking for alternatives to Windows forever. Then make it real easy to make these packages, if you want to support these old .EXE installers, or .ZIP packages - write converters. "Take your existing FoobarInstaller package as input and this will spit out a package with install and uninstall scripts". Maybe in the future support submission to the package repository in these formats and do the conversion automatically, but only store those real uniform packages. Set up a team to support conversion from various installers to the better universal format (but make sure it actually is better and able to do all the things people need from installers, incl. e.g. install device drivers). Next up use all that statistical data you're stealing from everyone's Win10 computers (gee, wonder why they don't want to upgrade again) and figure out what applications they are using that aren't supporting the new package structure, and go through every one of the vendors and help them convert. Microsoft is sitting on .. what, $100-$150 billion USD in bank, it's not like they can't do actually this, they just don't want to. Instead it seems people are building tools to use a GitHub repository with links to .EXEs to download and run them automatically from the CLI, one at a time, without a way to uninstall them, without a way to check what is installed, without a way to install any updates, without a way to ensure the version I've installed today on a new computer is the same it was yesterday on another computer (or maybe there's some magic around the PR system of that GitHub repo that I've not yet seen, who knows). |
Beta Was this translation helpful? Give feedback.
-
.MSIX packages work on Windows 7 SP1 and newer
NTFS permissions are not a new concept. This also applies to ssh-keys and many many other things - if you set the wrong permissions, you may have to restore/repair them to get it working again.
Such as?
This discussion about MSIX and winget is completely unrelated to the Windows Store. I get why you may not like the Store, but please realize that that has nothing to do with the topic at hand.
Exactly what I'm arguing for in this issue.
Exactly what I'm arguing for in this issue.
That is what MSIX does.
Not in the scope of this project, winget, but we could get pretty close to this with winget + MSIX + PowerShell DSC / ansible. Honestly probably good enough for most people.
Exactly what I'm suggesting in "3. Only allow .MSIX and .MSIXBUNDLE packages, but provide re-packaging CI for .EXE and .MSI". This is also my preferred option by the way.
Maybe a good idea, maybe not, but either way not directly related to this projects scope - remember, let's keep the discussion focused on the winget tool for now.
Exactly the problem I'm describing in this issue, and the reason I want Microsoft to ditch this approach entirely and focus exclusively on MSIX. Honestly, it feels a little bit like you basically agree with everything I said but just didn't read it past the title. If we take out some misinformation, like how MSIX supposedly doesn't work on Windows 7 or how you went off topic and talked about the Microsoft Store - then we're basically in near perfect agreement. |
Beta Was this translation helpful? Give feedback.
-
It has everything to do with the Store. Winget is becoming the engine behind the store. Store for Business incorporated into Intune already uses com api to pull applications using winget. |
Beta Was this translation helpful? Give feedback.
-
|
Winget has nothing to do with the store. Just because it supports calling out to the store and triggering a installation, does not mean that is its one and true only purpose. |
Beta Was this translation helpful? Give feedback.
-
So winget has nothing to do with the Store for systems admins that have to manage fleets using Microsoft Intune? The store for business was deprecated in favour of winget. I never said it was its one and true only purpose, this thread kinda started out that way by trying to silo winget in to being an msix deployment tool rather than an all purpose package manager. |
Beta Was this translation helpful? Give feedback.
-
Neat, I was misinformed then.
No, permissions are not a new concept. Installing applications in magically protected folders with permissions that I as the sole owner and Administrator of the machine have difficulty bypassing, and when I change those permissions the software blows up and refuses to run - these are new concepts, bad, definitely non-trivial, and not non-issues. Additionally these packages are implemented in ways that interfere with other software as mentioned. Try and install OneNote from Microsoft Store and then use OBS Studio to window capture it. You can't. Why? Because someone sprinkled some magic dust around these things. The same issues have applied to games installed via Xbox app, a more common use-case for OBS studio.
Everything you just called "trivial non-issues".
No, they are not unrelated. The Store is Microsoft's best "software repository" for Windows at the moment, and as such is inadequate. For an actual Package Manager to be useful, it requires a software repository.
Well maybe it should be in the scope. Any Package Manager is only as good as its packages. The package system + package manager can together make this easily possible when properly designed.
It's very much related to the claims about what is required for widespread adoption.
I read every word in this issue. My replies are not aimed only at you. I do not agree with MSIX being the solution when it literally is the cause of many of my headaches with software on Windows. I would just stop using Windows completely if it was the only way software was distributed. |
Beta Was this translation helpful? Give feedback.
-
That is an issue with OBS and something they have to resolve then. Other open-source screen capturing tools such as Captura can capture OneNote or other "UWP" apps just fine. There is no magic dust, these apps are just built on a different framework - maybe OBS has to add support for that, I get that. But that doesn't mean these apps automatically suck. Also, this is once again unrelated to MSIX. MSIX packages can contain either modern UWP apps, or more traditional Win32 programs - it's just a package format and unrelated to what is packaged inside.
Again, a slight adjustment from what you're used to, but by just adding
There are two scenarios here:
In that case, whatever the Store does or doesn't do is completely unrelated to this discussion.
In that case, the Store GUI will not be invoked - the usability complaints you have will not matter because you're using the Store as just a dumb file hosting service for your apps. You'll be using |
Beta Was this translation helpful? Give feedback.
-
|
You are all forgetting enterprise. Windows Store for Business has been deprecated in favour of winget. So any discussion around winget cannot disregard the Store. They may be technically independent of each other but there are dependencies here. |
Beta Was this translation helpful? Give feedback.
-
|
I think you just fundamentally do not understand the problem with the permissions - I do not want to "restore them", I've bumped into this issue and found those commands before, the fact that I need to for things to run is wrong, and the way they are set up and how Windows actively tries to hide the installed applications is flat out wrong. My suspicion is that they don't want people prying into all the garbage they are installing on Windows machines without my consent, like Candy Crush, but that's a bit beside the point. Similarly the way UWP/MS Store/MSIX or something is packaging the software is causing issues. Captura produces pretty bad results when I tested it, so I wouldn't consider it as proof of a solution existing. The OBS community has worked on the problem for years, without finding a reliable solution. This is still beside the point, I was primarily highlighting issues that MSIX and/or Microsoft Store (very related) have caused. I've really not seen many benefits to MSIX (can't name any right now), just a lot of problems caused by it. People just saying there are ways to restore the permissions and then ignoring all the problems others are having, is a part of the problem with adoption. Any serious Package Manager must include a serious Package Repository. Right now the only attempt for Microsoft to provide one is the Store, and it's deeply flawed. Using a GitHub repository with links is also deeply flawed as previously mentioned, unless some extraordinary ways to protect end-users from bad developer practices are in place. Right now what I see is links to files hosted on 3rd party servers (at least with SHA-256 sums, so that's at least a start). I've yet to see any GitHub based software discovery process working well - for one, GitHub itself limits the browsing of repositories once they get large enough, and e.g. https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types is an example of a kind of important repository having their usability reduced because they're relying on GitHub, good luck guessing if it includes the thing you are interested in. I would be somewhat surprised if today it was not already a problem that some of these registered download links to 3rd party sites would just geoblock downloads from the EU or other areas they don't like. There is likely no checks of the contents of those installers either, no verification that they actually contain somewhat functioning installers and uninstallers. Similarly download speeds are going to be up to the independent vendor's finances and capability to provide with geographically distributed release distribution infrastructure. These kinds of problems could be avoided with proper Package Repositories where you have multiple global mirrors. Anyway, it seems @jantari and I just fail to agree, and that part of the discussion isn't moving anywhere, so there is little point in continuing this back and forth.
Summa summarum, imo for
If the decision is that any of the 3 is "not in scope", the end result is going to be sub-par, and will fail to solve the real-world needs. |
Beta Was this translation helpful? Give feedback.
-
|
@doctordns With all due respect: upholding the current status quo isn't the remedy we need (but the one we deserve). If MSIX has a shortcoming that hinders adoption, the solution isn't to let the old creep in, but extend MSIX in a way that enables new use cases. (MSIX not being able to install drivers was mentioned as a problem but hey: maybe I don't want some less known screen recorder installing a driver on my system without it going through some screening like the Store or just regular WHQL to make it into Windows Update.) If we want to enable SW installing drivers, perhaps we should, but extend the manifest to not only warn users for Free+ (microtransaction), but also Free+ (installs a driver that can do whatever the hell it wants with your system). @lietu From your comments I see you revolving around two issues:
In the "not a package manager issue" I already outlined the way even the existing repo of YAML package recepies could be mostly reused to consume legacy stuff, convert them to MSIX and install those. It would bring legacy over to the "brave new world" through a roundtrip that with time will get tedious and ever harder to maintain. It will work in the short term, and will point in a better direction. If MSIX/Store/UWP/Windows/etc. lacks a crucial feature, the solution isn't to default to compatibility with 20 year old tech. Tainting the new with the old for the sake of a few shortcomings is... meh. |
Beta Was this translation helpful? Give feedback.
-
Except you can't, |
Beta Was this translation helpful? Give feedback.
-
|
This isnt' a package manager issue. Its a fundamental OS issue that should be solved by the OS team. |
Beta Was this translation helpful? Give feedback.
-
I very much do - with proper warnings and confirmations of course, if they are not certified - and these should be possible to bypass with CLI flags.
I very much like to decide for myself what I crack - if someone sells me a broken product, I need to have the right to repair it.
You may believe so, I do not. I believe the flaws greatly outweigh any minimal benefits.
It's not simple, unfortunately the world has a desperate need for perfect developers who never make a mistake and their software always works in every environment, not to mention the company/publisher/whatever in between the developer and me. I regularly need to replace DLLs for software I run with versions I know to work because their own search gives them the wrong ones. I regularly need to replace an .EXE with a version I want because e.g. I want mods on a game. I regularly need to modify content the developers might not have wanted me to change, but I really don't care if they wanted it or not. Intentional attempts to block me from doing what I want on my system are unquestionably wrong and unwanted. I'm sorry if you disagree but it's my computer and my way should be how it works, not the way some rando wanted it to be. It's like next you'll propose that I can't use my firewall to block always-online games and applications, because that's not how the developer wanted it to work.
Far from my main concerns, just one of the issues I've mentioned. You might have some cases where AMD's software built using e.g. their own staff's knowledge of undocumented direct hardware access methods might work differently, but that doesn't mean there aren't issues caused by this.
In that case it should work like it does on MacOS, there's a screen capture permission that needs to be enabled per application. Now there is no permission, it just gets blocked. And I cannot fix it. Because someone decided that if I try to fix things, the applications blow up. "But don't worry, you can restore permissions to their original state" - which still leaves me with a broken system I cannot do what I want, as the sole owner and administrator of the computer I've bought, built, and installed myself.
The way things are, the world needs less UWPs, there is basically nothing I like about them, and they're a huge cause of my daily headaches again. Oh don't want applications running in the background? Unfortunately that also disables Search Indexing - why? Because it just does. Don't want Mic access given to random applications by default? That's fine, but we'll also deny the software you want to use from using it, and not tell you why when you scream at the computer wondering why it "can't detect" your perfectly functioning mic.
There are not a few small shortcomings, minor hindrances, some unpleasant looking corners to polish .. there are massive significant headaches caused by MSIX and UWP, that Microsoft refuses to acknowledge, fix or in any way solve. All the while ignoring their users screaming on all their available feedback channels, and then continues to shove these things down their throat as the "solution". |
Beta Was this translation helpful? Give feedback.
-
This is a very shallow view of the mods and patches that are in common use today. Even utility apps benefit from these things: "BetterDiscord". There used to be an MSN one that prevented ping spam and removed ads. The list could go on, but to assume there's never a legitimate reason to want to locate the executables is naive |
Beta Was this translation helpful? Give feedback.
-
|
@jantari great discussion here. I wonder how the community would react if we were to add configuration options that prefer one installer type over another, or give the ability to ignore "non preferred" installer types. This could be a per machine config, or possibly part of policy manager options. We're looking at settings now with #396 Settings command. |
Beta Was this translation helpful? Give feedback.
-
|
This is a great idea. I see in many packages both exe and msi as an option, I would love to be able to specify I want the msi. Only because I always use overrides. |
Beta Was this translation helpful? Give feedback.
-
|
Add 👍 to: |
Beta Was this translation helpful? Give feedback.
-
|
Imo if I run Otherwise people will have to start writing their setup guides something like: "If your winget is using defaults, run |
Beta Was this translation helpful? Give feedback.
-
|
They wont have to, if they have the defaults modified to prefer a specific installer type or to ignore another installer type, as long as the package has a installer that fits all the qualifications and fits within the specified scope, it will be installed. If they don't have the defaults modified, they likely don't care what installer is used as long as the program gets installed in the end. |
Beta Was this translation helpful? Give feedback.
-
|
You do understand that people would package their own software for Linux if there wasn't 200 distros out there, and 4 major versions of each of them "active" at any given time? ... kind of like they do for Mac, though even on Mac it's not perfect, which is why you end up with homebrew and pals. Windows has a very different position from Linux, and Microsoft is clearly in a position to bring a new solution out there that gets rid of all the nonsense. Sure, you can keep delivering .exe installers if you want, or implement the standard format package (once a real good package format is created, I'm far from convinced that MSIX is any kind of a solution to the problems) and have it easily available for everyone without you having to figure out installers. This would require
There are already many solutions for running remote .exe installers, we don't need another one. If Right now The prognosis would be pretty different if These are things that others cannot really do easily, Microsoft has the weight, cash and just sheer volume of developers to push others to a good solution. Or they can keep fiddling around building an inferior runner for existing flawed installers. Nobody needs to get rid of .EXE and .ZIP distributions as they are right now, if people want to keep using those, Chocolatey, Scoop, and tools like Salt Stack can serve them just as well. What they need is a new solution, instead of trying to support every legacy thing ever invented. This new solution could then develop into something that everyone will WANT to use in the future. |
Beta Was this translation helpful? Give feedback.
-
|
Fundamentally, this is all that would happen. You can't try to force people to adopt a standard, it rarely ends well for anyone involved. |
Beta Was this translation helpful? Give feedback.
-
|
Microsoft can for enterprise. |
Beta Was this translation helpful? Give feedback.
-
|
I fear that if you have packages without package slots and without them being centrally managed, you will have never ending dependency conflicts. That's something that probably can't be resolved without a distro.
I can't agree more. They don't even have automatic registry updates. |
Beta Was this translation helpful? Give feedback.
-
|
Actually we have a solution available in our hands: MSIX, but MSIX on anything but Windows 10, aka MSIX Core. |
Beta Was this translation helpful? Give feedback.
-
|
Let's ask app developers if they could provide msix packages for their apps and even contribute manifests and add assembling them to their build for FOSS apps. Let's see if that goes well or it there will be any major issues. I think it's the best way to go instead of continuing this purely theoretical debate. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly! This is the fix right here. |
Beta Was this translation helpful? Give feedback.
-
|
For the most part people have said that they have no reason to switch to MSIX. In the case of Calibre, I think the developer said that the MSI (un)installer is already clean. Not even MS or its partners (Spotify, Chrome, Adobe, etc) are using MSIX. Speaking of hypocrisy, Skype recently switched from RNW to Electron. *facedesk* |
Beta Was this translation helpful? Give feedback.
-
|
Is there any reason for why the package manager couldn't support both the uncontrolled ZIP and EXE packages, and support the isolated, modern MSIX packages too? It'd be great if winget printed out a warning in the terminal when I try to install a package that uses an uncontrolled format. For example - if I want to install pgAdmin, I could open the terminal, type |
Beta Was this translation helpful? Give feedback.
-
|
This is a great option, it would make packaged MSIX files gain traction, and for the average joes who just want to install their own programs install their own programs. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is related to: |
Beta Was this translation helpful? Give feedback.
-
|
Supporting extra things is more work. If these "uncontrolled" ZIP and EXE installers are not packages, why would a "package manager" allow you to install them? Currently the "package manager" does not support any kind of package management, and the Windows world really needs one. This proposal seems to me to be mostly about getting the "package management" part done and leaving the other non-package management parts for others to worry about. There are existing tools to install them that do them better both for individuals and organizations than win-get, incl. Chocolatey, Salt Stack, and others. |
Beta Was this translation helpful? Give feedback.
-
I'm not sure what the problem is with ZIP? It's not going to go behind winget's back like EXEs do ... |
Beta Was this translation helpful? Give feedback.
-
|
portable apps are safe to place as a packaged app. |
Beta Was this translation helpful? Give feedback.
-
|
I can tell you what the problem with ZIP is, as I've had to create a deployment package for neovim not long ago so that I can roll it out to our Windows Servers at work: This is a screenshot of the steps I had to create during the neovim deployment package that it has to go through to install the software from a ZIP file. It's messy, and some of these steps contain small-sized scripts behind them. Installing a software from a ZIP package is not as easy as just expanding the archive, you have to wrap it in what basically becomes an installer anyway. |
Beta Was this translation helpful? Give feedback.
-
|
I can tell you what I would be thrilled to see Neovim in the Store. In fact it among the 3 projects I tried creating a Store-compatible package for (beside CMake and Doxygen). Always at most I get as far running it locally, but not once could I make the Store happy with a hand-rolled manifest. There are 3 errors I've no clue how to resolve:
The app with the highest value to developers would definitely be CMake and I got as far as getting the package to work locally, but the Store seems to be too damned picky. I tried both packaging the ZIP release fully manually based on the "Package from the command line" docs and running the MSI installer through the MSIX packaging Tool either as-is or touching up the manifest with patterns borrowed from the PowerShell's manifest and the MSIX Pack Tool itself. None seem to work as documented. |
Beta Was this translation helpful? Give feedback.
-
|
I'm converting this to a discussion. At present, we do not plan on eliminating support for .exe installers. I believe we will be enabling support for filtering packages by installer type. Once that is done, we could honor settings that prefer or require not installing packages with "InstallerType: .exe". There may be other feature requests that come from this discussion. We could also look at Group Policy settings that also prevent support for .exe installers. |
Beta Was this translation helpful? Give feedback.
-
|
Well...with the announcement of the new store last week and the following developer presentation and the infos in the new store guidelines, you could say that this discussion is now pointless, i guess. |
Beta Was this translation helpful? Give feedback.
-
|
@denelon wait so what's the windows 11 situation??? i go and install OBS and then it doesn't update through the MS Store??? |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
What really baffles me is how much effort they waste redoing the same thing over and over instead of fixing the problems by the root. |
Beta Was this translation helpful? Give feedback.
-
|
@Gabrielcarvfer - George Santayana says: those who can not remember the past are condemned to repeat it". I still can not really understand the motivation to start from fresh and totally ignore both PowerShell and PowerShell's Package Management. I will do what I can to get full PowerShell support for winget. Sadly, I feel this is doomed to be yet another power toy. I just can't see the motivation for another command-line tool that is not PowerShell based. We have the store and Chocolately for Home and solo users - why winget? And given the decision to not create cmdlets means IT Pros can/do just say no in the enterprise. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
How could this discussion ever be a thing if Microsoft themselves pack their software as |
Beta Was this translation helpful? Give feedback.
-
|
Yeah no, winget is supposed to be a package manager for Windows, if Windows supports exe-based installers, so should winget |
Beta Was this translation helpful? Give feedback.
-
Exactly. This reply right here stops this discussion point blank. It's NOT wingets job to change the eco system. |
Beta Was this translation helpful? Give feedback.
-
|
The Windows Package Manager includes a tenet to meet developers/packages where they are. Unfortunately, this does cause many sub-optimal experiences. We've continued to extend the schema and the validation pipelines such that they provide better experiences for customers. We've identified the following feature to improve experiences including the ability to specify installer types, and likely "ignore" or "refuse" specific installer types with arguments and settings. |
Beta Was this translation helpful? Give feedback.
-
|
We could in the future find out a way to convert installers into MSIX apps. I agree they should NOT be removed, otherwise nobody would actually use it. |
Beta Was this translation helpful? Give feedback.
-
|
Not in the future, Microsofts tool to convert installers to MSIX has been available for many years already: https://learn.microsoft.com/en-us/windows/msix/packaging-tool/tool-overview |
Beta Was this translation helpful? Give feedback.
-
|
Having a 3rd party convert vendors installers to MSIX with trusted certs is a bad idea for obvious reasons. That should be their job, and this is the problem. We should not cloud the issue that the lack of adoption of msix is not Microsofts problem or wingets. As usual its vendors. |
Beta Was this translation helpful? Give feedback.
-
|
Just to note: repackaging everything may violate the terms of service of a developer's program, and if the developer does not care to, you need the original exe. |
Beta Was this translation helpful? Give feedback.
and others
The Windows Package Manager includes a tenet to meet developers/packages where they are.
Unfortunately, this does cause many sub-optimal experiences. We've continued to extend the schema and the validation pipelines such that they provide better experiences for customers. We've identified the following feature to improve experiences including the ability to specify installer types, and likely "ignore" or "refuse" specific installer types with arguments and settings.