Scoop and Shims
Scoops uses shims which have numerous issues. On top of that, they are slow as Scoop uses .NET runtime to launch them. They also do not quite mimic the target executable, for instance an icon, version, metadata etc.
The main reason I think authors went for shimming is they wanted to “keep the PATH clean”. This does actually make sense - only one directory is in the PATH (the one containing shims) but not the others. However, in practice this often doesn’t work, and here is a proof from environment variables that scoop itself adds after installing certain software:
Still, I think Scoop at least made an effort.
My thinking is CLI tools in fact do not need any shims at all. Just add the entire folder where it’s installed to system path. It’s much better. If it’s a CLI tool, most often the only thing it has is a single .exe, maybe a few .dll files. So having it all in is much better, and as the picture above says is often required.
How, GUI software is different. In my opinion, it does not need to be in system path at all, or have shims for that reason. In fact, shimming it actually does the opposite - pollutes system path. What happens when you install software manually via some installer? It just goes to “Program Files” whatever, and the installer creates a shortcut (desktop, start menu etc.). That’s it.
I’m currently in love and hate relationship with Scoop. It has numerous issues on the local PC such as CLI client is really poor and slow (just try search). Usage of git to store manifests, and manual approval processes for new software. Writing manifests is really awkward and far from obvious, and manual PR reviews’ comments are far from helpful.
Maybe it’s worth if someone starts writing a new package manager?
To contact me, send an email anytime or leave a comment below.