-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simply incorporate Scoop completely into WinGet. #1262
Comments
Any thoughts on this? |
@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. |
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. |
@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.
|
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? |
@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. |
what we got so far: |
We are currently working on: Next we will work on: 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: 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). |
Chocolatey support would be nice too. |
...
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. |
Scoop serves a completely different niche than winget (mainly serving portable programs that don't include auto-updaters), not to mention that installing scoop on a new machine is a completely trivial one-liner. |
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.
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
Proposed technical implementation details
wg
prefix to avoid naming collisions with an existing installation of Scoop.wgScoop.ps1
from an appropriateRunspace
.wgScoop.ps1
.WinGet-
to their repository names. Execute repository moderation bots on these repositories.wgScoop
sources to use the forked repositories.$env:UserProfile/scoop
to$env:UserProfile/.winget/wgscoop
wgScoop
via environment variable.An Aside
The text was updated successfully, but these errors were encountered: