Repository navigation
Shims like Scoop #361
Description
Activity
I'm using scoop instead of choco just because it adds the essential apps to the path automagically.
Reacted by Witchilich, Suhail Malik, ylor, Mario Gabriell Karaziaki, I-Want-ToBelieve, Pratik Chowdhury, Fujita Hitoshi, Marek Lukáš, harvastum, Moheshwar Amarnath Biswas and 1 moreBogDan Vatra (@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.
Reacted by antiufo and EvgenyJust to be clear, Chocolatey has this functionality as well, and has for a long time.
Reacted by antiufo, Rob Reynolds, Poopooracoocoo, Bernd Eichelberger, Haoran Ni, George Simos, w3lld0ne and Lloyd Atkinson- added this to the milestone
on May 29, 2020 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 - [Enhancement] Replace Batch Redirector with Shims 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).
Reacted by Marek Lukáš, Bas van den Wollenberg, Wes Higbee, Poopooracoocoo, Haoran Ni, Roy Ivy III, mooh-pooh, Hans Martin Galliker, George Simos and Martin Hinshelwood nkdAgility.comWindows 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
Reacted by ivaquerozz, Poopooracoocoo and Kim WalischWe are working on support for portable / standalone executables like NuGet. This mechanism is being considered as a part of:
Demitrius Nelon (@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
Quang Kieu (@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.
Reacted by Peter Jonas, Camilo E. Hidalgo Estevez, Anders, blafrank, jantari, soredake, Martin Hinshelwood nkdAgility.com and WarmWelcomeNot 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.
Reacted by blafrank, Kaarel and Martin Hinshelwood nkdAgility.com- removed this from the milestone
on Nov 14, 2024 From my observation some packages already start using this feature, like
astral-sh.uv.So maybe we can close this issue since it has been already resolved?
get-command uv CommandType Name Version Source ----------- ---- ------- ------ Application uv.exe 0.0.0.0 C:\Users\user\AppData\Local\Microsoft\WinGet\Links\uv.exe
From my observation some packages already start using this feature, like
astral-sh.uv.So maybe we can close this issue since it has been already resolved?
The
astral-sh.uvpackage uses a portable installer, so it can use thePortableCommandAliasfeature. This discussion is mostly about non-portable installers.
Description of the new feature/enhancement
Like how Scoop has. For example without adding anything to path, we can just type
gpu-zto launch GPU-Z or use mpv.net from commandline withmpvnet <url>. UWP apps also have this,notepadsfor Notepads,wtfor Windows Terminal etc.