> Simpler than packaging. Scoop isn't a package manager, rather it reads plain JSON manifests that describe how to install a program and its dependencies.
I haven't tried WinGet, but Chocolatey still seems like the best package manager on Windows. Which is unfortunate, as it's very unfriendly to use, promotes their Pro plans too agressively, and like the article says, slow.
[1]: https://github.com/lukesampson/scoop/wiki/Chocolatey-Compari...
In fact it took far too long for chocolatey to even consider _uninstall_ that it was a total mess for years while maintainers played catch-up.
Scoop, by contrast, keeps everything user level and installs programs to its own folder in Documents aiming to portable.
Scoop is a fair amount simpler and doesn’t have any sort of pro version to upsell you on. Scoop’s catalog is smaller but still pretty well managed.
One key difference is that there's no such thing as a Scoop "package", unlike with Chocolatey. You can't build a file that can be moved and installed offline, since Scoop downloads and extracts it from a URL. I suppose you could setup a local proxy and workaround it, but it's not the main use case.
I use both since Scoop is limited in the installers it supports, preferring Scoop when a program is available there.
There are some manifests that break it since they absolutely have to (like the VC++ Redist), but for most of the apps, Scoop actually acts a whole lot like a package manager.
Scoop seems awesome too, just doesn’t fit my particular needs
There is Chocolately too, but I've never been a fan. The website is horrible for one thing, but there are 2 big problems: package updates sometimes take forever, and there are frequently multiple "versions" of a given application, made by different people - how do I know which one is the better quality, and how do I know which is more likely to be updated in future?
Updates take forever ? What does that mean and why would you care tbh if it takes minute more or less as it is unattended ?
I mean, it is a chocolatey, because they allow multiple packaged for the same software. I don't have this problem with scoop.
> You can use one with most downloads.
Sometimes it's that simple, but other times there are material differences between the packages, or multiple packages with about the same number of downloads. And then in the comments for package A you have people saying "this is rubbish, use package B instead!"... and of course, in the comments for package B you have people saying "this is rubbish, use package A instead!". Honestly, I can't be bothered with it - package managers are supposed to make things easier.
> Updates take forever ? What does that mean and why would you care tbh if it takes minute more or less as it is unattended ?
I didn't mean the time the actual install took, that's clearly nothing to do with chocolately - I meant that packages are often not updated by the maintainers.
I think this is more healthy then having one with maintainers refusing to do stuff you may need. The real thing would be for vendors releasing packages but we are far from that in Windows land. My hope for MS WinGet was that since it is backup from MS that vendors will adopt it, but since it sucks, this will probably not be the case.
> I meant that packages are often not updated by the maintainers.
Yeah, that was the problem far more before then today. I created AU to solve that issue [1].
- It's difficult to get Explorer shell integration to work.
- Apps are not installed in their expected locations, so Git Extensions won't recognize Notepad++ unless you tell it where it is.
- (the worst) Every application has at least 3 different EXE locations: the EXE in the shims folder (added to PATH, spawns the actual application as a child program), the EXE in the "current" folder-symlink (pointing to a specific version), and one EXE in every version's folder. And if you pin one of these to the taskbar, or associate a file extension to one of these programs, subsequent updates or app launches might open a different EXE that gets mapped to a different taskbar icon.
Explorer shell integration works just fine for me (7zip etc.), what app is giving you problems?
The fact that Scoops installs apps to a specific location may be sometimes problematic, but it's also the thing that makes Scoop great. In reality it's mostly stuff like you said, a one-off process of setting the current path.
The rule of thumb for the shims is to use the path with the "current" symlink. The exe in the shims folder is just a shim for CLI use, and version-specific folders are there just for updates/rollbacks. Windows may pin the "version name" path instead of the "current" path, but Scoop actually creates correct Start menu entries for GUI apps automatically (so you can pin that) or you could manually edit a .lnk's path and pin it.
VS Code (Codium), Notepad++, possibly Git Extensions, forgot what else (maybe Windows Terminal) create Explorer integration if you check certain boxes in the installer. And Scoop skips the installer, and you can't add integration after the fact.
You can install, update, and uninstall software.
And it also won't leave crap on your machine - everything is portable by default, and sits on a single folder.
Installing software with scoop gives me peace of mind.
The Scoop GCC manifest (and everything that depends on it) has been broken since January. GCC for Windows is now distributed using an unsupported archive format, and development to support that format has stalled out. https://github.com/ScoopInstaller/Main/issues/1752
Someone made a workaround patch using a different GCC mirror, but it's been sitting open for a month. https://github.com/ScoopInstaller/Main/pull/1933
One of the maintainers seems to be forking the scoop client, but their fork still uses the unmaintained main package bucket. https://github.com/Ash258/Scoop-Core
I'm pretty unhappy with the behavior of the maintainers to the author, though. There are better ways to suggest issues with documentation than just "this is a lie", and better ways to say a function name could be better than "is a horrible name". I also think it's rude to ask for a patch to be completely rewritten and then ignore it after the author does so.
Looks like a frustrating choice between a polite maintainer that isn't around or a rude maintainer that is still active.
However, his comments are often harsh, like you noticed. He's mostly on-point, but is very quick to rudely shoot down anything he disagrees with. Also he bans discussing or even mentioning his fork of Scoop on the Discord server, which is super weird since he put it publicly on GitHub in the first place.
Check Merged PRs https://github.com/ScoopInstaller/Main/pulls?q=is%3Apr+sort%... and you will see that the last non-bot one was merged 17 days ago.
Well if it is dead then that is a damn shame.
For the most part, this does not matter. Most of the existing stuff is already present in buckets and auto-updated by CI. The problem is just when something breaks or something new needs to be added, which can take a non-deterministic amount of time.