Simply incorporate Scoop completely into WinGet.

[sharpninja]

Incorporate Scoop in its entirety into WinGet.

Currently, the Scoop package manager is the most convenient place to get software for Windows, especially open-source software that does not require an installer or makes no installer available.

Incorporating Scoop would expand the library of software available for WinGet to distribute and manage.

• Scoop would be treated as a secondary source, like with MS Store.
• Scoop commands not in WinGet would be added to the WinGet command set and would default to using Scoop as the source.
• Installing on systems with existing installation of Scoop would offer to update that installation to the version included with WinGet
• Assimilating an existing scoop installation would reset permissions to use buckets other than the main bucket.
• Assimilating an existing scoop installation would alter the Scoop.ps1 shim to redirect to calling WinGet.
• WinGet would be able to uninstall packages installed via Scoop to build on the capability to uninstall any package from the registry.

This would give users a clean way to get "flat" apps without an installer and leverage the thousands of packages already submitted to Scoop. Microsoft could fork the repos for the buckets and curate them and only allow the curated buckets and include those repositories in the same submission workflow as WinGet.

Licensing

Scoop's License

This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or distribute this software, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any
means.

Proposed technical implementation details

1. Fork Scoop
2. Rename all files to include a wg prefix to avoid naming collisions with an existing installation of Scoop.
3. Create a wrapper class in WinGet that invokes wgScoop.ps1 from an appropriate Runspace.
4. Add missing commands to the WinGet command line parser, defaulting them to call wgScoop.ps1.
5. Fork all Scoop manifest repositories, prefixing WinGet- to their repository names. Execute repository moderation bots on these repositories.
6. Update wgScoop sources to use the forked repositories.
7. Change the root folder from $env:UserProfile/scoop to $env:UserProfile/.winget/wgscoop
8. Allow setting the location of the root folder for wgScoop via environment variable.
9. Import documentation from the Scoop Wiki into the official WinGet documentation.

An Aside

Please consider 💲💲compensating💰💰 the team behind Scoop for their years of hard work with either a generous cash offer or other financially beneficial arrangements. Just because their license would allow all of this without compensating them, it is only right to fairly compensate them.

@sharpninja

[sharpninja]

Any thoughts on this?

[denelon]

@sharpninja we haven't built support for standalone .exe or .zip packages yet. Our current thinking involves treating them more like a program so we can have entries in Apps & Features. That would enable upgrade and uninstall scenarios.

I've seen a few references to the use of shims with Scoop which is something we would likely avoid in the Windows Package Manager. Scoop has a vibrant community with a working solution to a non-trivial problem. There may be a way to leverage the repositories at some point in the future, but I don't think we're far enough along to discuss the pros and cons yet.

I saw ScoopInstaller/Scoop#3992 a while back, and I have to agree with some of what has been stated. In particular, I believe the Windows Package Manager and Scoop were built to address slightly different problems. Each different package manager has taken a slightly different approach to managing software (and the different types of programs). I don't think there is necessarily one right solution. Different individuals and different problems prefer a different approach.

[sharpninja]

It seems to me through that fragmentation is bad for the whole community. If MS wants to truly embrace Open Source, part of that is knowing when to incorporate another projects freely available code instead of reinventing the wheel.

[denelon]

@sharpninja the goal is not to reinvent the wheel. I agree about knowing when to incorporate other projects. We have already included several other open source projects into the Windows Package Manager. This is more about how various requirements related to security, compliance, and consistency across the product should be handled. A list of qualities from AppGet influenced our design. They are listed on a blog post about "winget install learning" and copied below.

• No scripts during install – something that we completely agreed with and don’t allow with MSIX
• Rich manifest definition within GitHub – the power of being open combined with rich declarative meta data about the app is so important to meet goal #​1
• Support all types of Windows applications installers
• Seamless updates for applications in the repository

[sharpninja]

Ok, looking at a different angle, what is needed is a tool to create msix files based on scoop's metadata, but then who signs the msix files?

[denelon]

@sharpninja I don't think we're planning on building an MSIX for a .zip or portable .exe. I think we're looking to do some custom work/behavior in the client such that when we encounter one, we can use the meta-data from the manifest to build an entry for Apps & Features. We'd be able to display the publisher and version information as well as specify a path where the executable is on the drive. Then in the future when a new version is created, we would be able to perform a logical upgrade by laying the new executable down in the proper location. If a user were to "uninstall", we would have the ability to remove the directory the file(s) lived in, and remove the path entry. There is certainly more scoping (where do these get installed, what about files created in the same directory, etc.) needed to be done, and plenty of edge cases to deal with, but that's some of the current thinking.

It is reasonably simple to create an MSIX for an executable, but the signing is often the barrier. I know there are services being built to make it easier to perform code signing. Plenty of third party providers also have tooling to make it easier to build MSIX packages and sign them as well. It usually falls into the concern of cost after the complexity of code signing.

In the case of portable .exe or portable / standalone apps in .zip files, the publishers and often the users still prefer just to have the binary and not have the overhead of an installer in some cases. We're trying to meet developers where they are.

[keentext]

• Support all types of Windows applications installers
• Seamless updates for applications in the repository

what we got so far:
no support for zip/binaries, no proper support for uninstalling stuff, win store is messed up with win 10
winget will not update some stuff, win store is broken, even installing through winget may mess up your system (it allows software already installed to be installed again)

[denelon]

We are currently working on:

• Support for installation of portable/standalone apps #182

Next we will work on:

• Support installing .zip files #140

The Windows Package Manager codebase is C++ so incorporating Scoop would not expose the capabilities in the "winget" command line interface. We do plan on having:

• When do we begin to see the PowerShell cmdlets? #674
• Add Native PowerShell Support #221

Once we have PowerShell cmdlets released, it may make sense to revisit discussions to see if it is reasonable to expose mechanisms to leverage functionality across both products or find ways for each product to leverage the others "catalog" of packages (or a subset of them).

[upintheairsheep]

Chocolatey support would be nice too.

[luxzg]

We are currently working on:

...

Once we have PowerShell cmdlets released, it may make sense to revisit discussions to see if it is reasonable to expose mechanisms to leverage functionality across both products or find ways for each product to leverage the others "catalog" of packages (or a subset of them).

So... With all the checkboxes checked, could we get an update to this?

Winget has progressed a lot, but having a way to benefit from the scoop"s buckets would still be great.

Also, no one mentioned one other possibility, but maybe think about a way to translate scoop buckets to winget repositories? Even if partial, and for example excluding entries with scripting and similar elements that you want to avoid, using anything from buckets would be big thing for winget users.

I have to admit I am way behind on winget updates, but last time I checked scoop still offered 90% of packages I use on a daily basis (basically everything except games and MS Office), while winget didn't even get close. While the time since then surely helped closing the gap, I still think winget could benefit from scoop and/or buckets in some way.