Shims like Scoop
Witchilich opened this issue · 12 comments
Description of the new feature/enhancement
Like how Scoop has. For example without adding anything to path, we can just type gpu-z to launch GPU-Z or use mpv.net from commandline with mpvnet <url>. UWP apps also have this, notepads for Notepads, wt for Windows Terminal etc.
I'm using scoop instead of choco just because it adds the essential apps to the path automagically.
@bog-dan-ro Scoop does not add anything to the path. It adds their Shims directory to path and adds shims to that path. Same as UWP's 'WindowApps' directory.
Just to be clear, Chocolatey has this functionality as well, and has for a long time.
To follow up on what Gary mentioned and make sure the credit is in the proper place, I just wanted to note that Chocolatey brought about the idea of shims not to clutter your PATH - it existed long before Scoop was created as a concept called batch redirects. Later we moved to shim exes. Luke thought shimming was great and added it to Scoop. Just want to make sure the credit is in the proper place on shims.
References:
- November 2013 - Issue for Shim Exes for Chocolatey w/commits in November 2013 - chocolatey-archive/chocolatey#372
- January 2014 - Added to Scoop - ScoopInstaller/Scoop@5c52166#diff-6102f557c61df6fb4e37e4e68d8899348e48b633871262f5fd1c27ed42caf4dd
I think your confusion might be in that Chocolatey could defer to an installer as well, which might put things on PATH. Scoop doesn't use the installer at all, it just unpacks, so the shims are much more necessary. Chocolatey's docs on this - https://docs.chocolatey.org/en-us/features/shim
(NOTE: This is a repost of what I noted on a different issue).
Windows already has some kind of shim in windowsapp folder. Like wt.exe for windows terminal; wsl.exe for the lixus sub system
I think the manifest need someway to specify which to shim from final install folder
We are working on support for portable / standalone executables like NuGet. This mechanism is being considered as a part of:
@denelon as taking about shim, I wonder if we could request open version of windows store shim for like wt.exe, wsl.exe to use in personal project
@quangkieu what you are referring to is an App Execution Alias I believe. This is part of the behavior supported by MSIX packages. https://docs.microsoft.com/windows/msix/desktop/desktop-to-uwp-prepare
Windows Package Manager 1.3 preview releases and the Windows Package Manager 1.3 release candidate use symbolic links for portable applications to avoid cluttering a user's path environment variable. We're still discussing the relative value of trying to create a mechanism affecting the path when an installer is used for a package. We've added install notes to give users information about a recently installed package that could contain information like the requirement to restart the terminal session to get any potential path entries that have been made by an installer.
If an app depends on some .dll file within its directory, symbolic links do not work. Also, symbolic links require admin permission.
Not every Windows executable supports command line usage. We should be able to list the ones that do in the app manifest and then the shims for them would be created automatically in an existing directory that's already in PATH.
restart the terminal session to get any potential path entries that have been made by an installer
That's what we want to avoid having to do 😉. Both the restarting of terminal and the pollution of PATH with new directories are bad.
FWIW, Homebrew also creates shims (or rather it permits maintainers to do so in the app manifests). See Homebrew/homebrew-cask#18809: "Everyone agrees shim scripts are desirable, so lets allow them."
Winget is more modern and IMO more elegant than the other package managers, but this pain point is a major inconvenience that makes it difficult to recommend right now.