Not a package manager

[pac85]

The description claims this thing to be a package manager but in reality it has nothing to do either with packages or management.
All it does is downloading installers (which are not packages) and executing them (which is not management).

[erolm-a]

Even though it also keeps track of installed packages and gives an unified command line interface to call their uninstaller. Basically what the Control Panel had for years, but extended to the terminal.

However, Windows installers have a long history of not tracking down all the pollution they make in the Appdata section, the register and a couple other places, whereas any other "real" package manager does (and allow for diversions too!, see dpkg).

EDIT: Oh it seems like there is not yet support for uninstalling?

[ItsMeAubey]

EDIT: Oh it seems like there is not yet support for uninstalling?

If you look at a manifest (https://github.com/microsoft/winget-pkgs/blob/master/manifests/Adobe/AdobeDigitalEditions/4.5.11.yaml as an example), this is essentially a glorified .exe downloader and installer (opener? runner? Winget isn't actually doing any installing), hence the lack of uninstall functionality. As of now, it can only be considered a "package manager" if .exes are considered packages.

[codgician]

This actually reminds me of scoop. I hope advanced package management features like version management could be supported in future.

[hcyang99]

The world is small LOL

[AdrianoCahete]

Looks like that their idea is to be a package management, but this first alpha version just download files. You can see their plans in the Project page.

[ItsMeAubey]

[cjwijtmans]

I have always wanted portage on windows.

[AdrianoCahete]

How about instead working towards integrating an existing fully featured, highly developed package manager, like APT, RPM, Pacman, Zipper, Portage, or any of the other fully featured ones that have existed for years? This project is a solution in search of a problem.

From their page announcement:

Why not contribute to another open source package manager?

We looked at several other package managers. There were several reasons leading us to create a new solution. One critical concern we had was how to build a repository of trusted applications. We are automatically checking each manifest. We leverage SmartScreen, static analysis, SHA256 hash validation and a few other processes to reduce the likelihood of malicious software making its way into the repository and onto your machine. Another key challenge was all the changes required to be able to deliver the client program as a native Windows application.

[cjwijtmans]

Yeah because it is so hard to fork a package manager and create their own repo. This just shows they dont understand package managers even more.

[bish0polis]

https://xkcd.com/927/

We are automatically checking each manifest. We leverage SmartScreen, static analysis, SHA256 hash validation and a few other processes to reduce the likelihood of malicious software making its way into the repository and onto your machine.

I like how all of these are possible in many existing and established package managers.

[ItsMeAubey]

[cjwijtmans]

IF what you say is true they should never have advertised it as a package manager on the microsoft website.

[AdrianoCahete]

You must convince Microsoft and their employees then. ¯\(ツ)/¯

[KiruyaMomochi]

If a package is using msi/msix or portable format, it somehow can be a package?

[aclinick-zz]

Happy to get feedback and also happy to understand where you'd like us to get better. One of the goals was to enable people to easily get the apps that they already use without having to make the apps change. The ability to script what is required to setup a developer machines was a very commonly requested feature as was being able to use existing apps.

As you may know MSIX provides a more complete versioning, app/package management capability and of course winget supports that but that does require the app to change to package as MSIX. Obviously we would love it if people do that and we encourage them to do so. Once you're in MSIX we can keep the app up to date, uninstall cleanly plus understand what dependencies are required etc. The decision to support both older apps and MSIX was the right solution to deliver value today and help the ecosystem move forward.

Again would love to hear your feedback on whether that's the right choice and github is a great place to give that feedback :)

[darkpixel]

@aclinick Publish the specs for MSI/MST files, open source the tools for reading/writing them, and open source the Windows Installer. It's a decent package manager for Windows...

[aclinick-zz]

We open sourced MSIX since that's what is under active development and we believe is a better solution https://github.com/Microsoft/msix-packaging Love to get your feedback on that too :) Includes cross platform implementations too plus makemsix to assist with building msix packages on Linux build servers.

[VincentJoshuaET]

Is it possible that all applications in the repository must be packaged as msix first? That would be much cleaner.

[tresf]

Scoop does this fantastically, in user space and even can work with some dev libraries. It doesn't have a trusted location for precompiled binaries (homebrew is able to pull this off), but instead scoop uses upstream mirrors.

vcpkg is a nice project for devs but last I checked it compiles everything from scratch.

To have both features... software and development libraries available via command line (like apt, brew, pacman, yum) is so important for Windows. Merging the good parts of all projects would make development on Windows much more attractive. ♥️

[cjwijtmans]

I dont know if you realize but package managers exist that can both compile and install binaries. You know why? Because they are actually package managers and not glorified command line app stores.

[aclinick-zz]

As much as we would like all apps to move to msix before listing that would significantly reduce the availability of apps. We are working with ISV's to move to msix so the goal is that over time apps would move to msix but that will take time.

[Croydon]

If the current packages don't have options yet, they probably should get some form of options concept. VS won't be the only application where individual options are wanted

[denelon]

All, sorry for the long silence here. @KevinLaMS and I have been fielding all of the issues coming in for the client and the packages. There has been quite a bit of activity. I'll attempt to walk the threads here and reference the Issues where we already have a feature on the backlog. When we've distilled the discussion to gaps in functionality, or decisions that need to be made, hopefully we can have a single issue per topic.

[denelon]

@erolm-a uninstall #121 is coming soon.

[denelon]

@pac85 dependencies is #163. I'm expecting we're going to have quite a few challenges with this one to support the various kinds of installers and things like which version of a language or runtime for IDEs that require one.

[denelon]

@rc-05 we already have support for multiple "sources". What's not out there yet is the #118 REST API to make it easier to develop your own source over a signed package such as the default source today.

[jvintzel]

As much as we would like all apps to move to msix before listing that would significantly reduce the availability of apps. We are working with ISV's to move to msix so the goal is that over time apps would move to msix but that will take time.

Spotify's a partner of MS but when you go to download it for Windows it downloads an exe :/ And as others have mentioned, not even MS has gone all in on MSIX. edge

Agreed everything is not MSIX at this time. Microsoft is on the path there along with other ISVs. In some cases it needs to align to a new version of the app as most isvs are not changing installer techs on .x releases, which is understandable. We recently hit the date that 1703 went end of life and 1709 and later supports MSIX, so that helps with a consistent Windows 10 story.

[jvintzel]

I can't understand the point of this. Instead of giving a cli to the windows store, this is just another "reinventing the wheel" and creating further confusion with another -incompatible- repository.
I think other package managers (or pretending to be ones) could be easily adapter to integrate all the tools and to use another repository.
Probably the best thing cold be help other companies to publish apps in the appx/msix format (and adding a way better documentation than the current one?). In this way newcomers could use the store and power users/corporate could use the cli to deploy faster.

The MSIX docs are all on GitHub, it would be great to get feedback there for what you would like to see more of or where areas are unclear. https://aka.ms/msix

[peter-dolkens]

@KevinLaMS

RE: Visual Studio, I almost feel like the default should be nothing but a shell, and all the other features should be optional things you can turn on, either through additional parameters to the install command, or additional payloads

I did similar for Mongo - the MongoDB server installer lets you install monitoring, routing, client, and server components individually (via MSI features) - so I split the 2 I thought were most useful (client and server) out to MongoDB.Server and MongoDB.Client

I'm aware of the interactive bug - I believe I have probably raised a duplicate

I'm not sure of the feasibility, but it might be nice to be able to interrogate packages that support a standardized "feature" set (e.g. MSI) for a list of features to install. e.g. winget describe VisualStudio.Enterprise (only problem being VS doesn't use MSI of course)

We could then install those interrogated features via a flag, e.g. winget install VisualStudio.Enterprise -f AzureTools,NodeTools

The manifest could even allow us to manually describe those features for the cases like Visual Studio where there isn't a standardized format that can be interrogated to determine them.

[MathiasMagnus]

@denelon @jvintzel What are your thoughts on Winget package .yaml files playing the role of portfile.cmake files in Vcpk land? (my prev comment)The YAML files would guide the MSIX Packaging Tool to execute stuff in Hyper-V or Docker, to ultimately result in an MSIX which then either makes it into the Microsoft Store, or a repo affiliated with Winget. (The latter is the moral equivalent to a PPA in APT land.)

If MSIX is a no-go for so many people (details in #407), perhaps MSIX should consider --classic confinement which is an escape hatch for use cases that don't fit the current sandbox model. Users get a warning when installing such packages (like VS Code). MS Store app page could have a standard warning for packages not running in a sandbox and that users need to trust the package vendor.

[lietu]

If there is an extra warning, then developers will not use it as other options do not get extra warnings and their users will find it shady and not install their software.

[denelon]

I've just enabled GitHub Discussions. I'm converting this Issue to a Discussion.

[peter-dolkens]

Hi @denelon - one thing that is a bit of a disappointment with winget - I'm connecting and developing on a remote machine via ssh almost exclusively at the moment. Unfortunately, running winget via the OpenSSH server returns an error, so I'm actually finding myself writing curl/pwsh scripts to install / manage dependencies instead.

This is extremely obvious at the moment, as I'm working devops supporting both win and mac teams, so it becomes very obvious when I can brew install docker but I can't winget install docker, for example.

vs

And to be clear - everything runs fine when I RDP into the machine, but it defeats the purpose of having remote shells available if you have to RDP in any time you want to install a tool.

[ShadowJonathan]

Converting this into a "discussion" isn't going to make any concerns raised here any less relevant, this should've stayed an issue.

[denelon]

@ShadowJonathan I converted into a "discussion" as there were several topics that weren't really scoped well to a feature. I expect multiple Issues to be created as a result of the discussion. @peter-dolkens does this Issue match your experience?

[peter-dolkens]

Hey @denelon,

Looks about right - I believe it's actually an issue in OpenSSH however:

PowerShell/Win32-OpenSSH#1632

[silvernode]

The description claims this thing to be a package manager but in reality it has nothing to do either with packages or management.
All it does is downloading installers (which are not packages) and executing them (which is not management).

If Winget becomes a real, full blown package manager, it would be a great way to keep me happy using Windows 10. In it's current form I really like it and appreciate this project a ton. Thanks to the contributors for all the hard effort.

[denelon]

Thank you @silvernode. I'll share the comment with the team. By the way, I just published a new release. It's making it's way through the store now.

[doctordns]

Where are the Powershell cmdlets? These should have been released a lon time ago. Say, winget remains a developer power toy. :-(

[bugproof]

The legitimacy of the packages is pretty doubtful as well.... I am scared to install some malware because I don't know if the source of downloaded package is official. There are some non-english packages too like КриптоАРМ ГОСТ TrustedRu.CryptoARMGOST 2.5 winget

[ItzLevvie]

The legitimacy of the packages is pretty doubtful as well ... because I don't know if the source of downloaded package is official.

By policy, all WinGet packages are downloaded from the official publisher's website. This means that you can always verify the InstallerSha256 against the official publisher's website to ensure what you have downloaded from WinGet Client has not been tampered with by a malicious actor during the downloading process of the installers.

Most of the WinGet packages themselves are unofficial and published by the helpful community—just like how it is done for Chocolately—however the Download URLs are not unofficial and comes straight from the official publishers or official vendors.

WinGet package repository will have the "verified publishers" feature in the future that will allow official publishers or official vendors to take control of their packages instead of a random contributor which will greatly reduce the risk of a security or malware issue.

WinGet Client also has the Microsoft Store (msstore) source where you can download applications from. It will probably be the default pre-defined source in the future once it has parity with the Community Repository (winget) source in terms of functionality.

Unpackaged Win32 apps can now be allowed in the Microsoft Store ever since Windows 11 released and this was also backported to Windows 10 several months ago.

Many official publishers or official vendors have started to upload their applications to the Microsoft Store as a result of this. Common examples are Zoom, TikTok, Discord, and more.

I am scared to install some malware.

This situation has been discussed over at microsoft/winget-pkgs#19462 (comment) but the answer here is that you will be unable to download any sort of malware installers through the WinGet package repository as there are various checks and scans in place to prevent that.

Even if one malicious package accidentally went into the WinGet package repository, you will likely see "An anti-virus product reports an infection in the installer." in your terminal which will prevent you from forcefully trying to install that package via winget install or winget upgrade. This is not any worse than what other package managers do in this area such as Scoop and Chocolately.

If you are unhappy with this you have the ability to create your own WinGet package repository using https://github.com/microsoft/winget-cli-restsource. This means that you will be the only one that can make changes to your WinGet package repository and no one else is allowed to make changes to your WinGet package repository.

There are some non-english packages too like КриптоАРМ ГОСТ TrustedRu.CryptoARMGOST 2.5 winget

All of the WinGet packages have to match what's shown in Control Panel's Add or Remove Programs (ARP) to properly map the application to the winget list command as the WinGet Client heavily relies on the data provided from the Control Panel (\Microsoft\Windows\CurrentVersion\Uninstall registry entries).

Most of the WinGet packages that have weird package versions and package names will be resolved in a future WinGet Client release.

WinGet packages that are not in English are allowed to be submitted into the WinGet package repository to support users that are Chinese, Russian, Japanese, and more.

The Windows Package Manager team is looking into improvements in the future to allow users to filter the search based on locale, that is if you do not want to see any WinGet packages that are not in your locale.