Skip to content
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

Shims like Scoop #361

Open
Witchilich opened this issue May 29, 2020 · 12 comments
Open

Shims like Scoop #361

Witchilich opened this issue May 29, 2020 · 12 comments
Labels
Issue-Feature This is a feature request for the Windows Package Manager client.

Comments

@Witchilich
Copy link

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.

@Witchilich Witchilich added the Issue-Feature This is a feature request for the Windows Package Manager client. label May 29, 2020
@ghost ghost added the Needs-Triage Issue need to be triaged label May 29, 2020
@bog-dan-ro
Copy link

I'm using scoop instead of choco just because it adds the essential apps to the path automagically.

@Witchilich
Copy link
Author

@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.

@gep13
Copy link

gep13 commented May 29, 2020

Just to be clear, Chocolatey has this functionality as well, and has for a long time.

@ferventcoder
Copy link

ferventcoder commented Mar 19, 2021

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:

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).

@quangkieu
Copy link

Windows already has some kind of shim in windowsapp folder. Like wt.exe for windows terminal; wsl.exe for the lixus sub system

@quangkieu
Copy link

I think the manifest need someway to specify which to shim from final install folder

@denelon
Copy link
Contributor

denelon commented Feb 18, 2022

We are working on support for portable / standalone executables like NuGet. This mechanism is being considered as a part of:

@quangkieu
Copy link

@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

@denelon
Copy link
Contributor

denelon commented Feb 18, 2022

@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

@denelon
Copy link
Contributor

denelon commented Jul 7, 2022

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.

@KaranKad
Copy link

KaranKad commented Oct 9, 2022

If an app depends on some .dll file within its directory, symbolic links do not work. Also, symbolic links require admin permission.

@shoogle
Copy link

shoogle commented Nov 1, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Feature This is a feature request for the Windows Package Manager client.
Projects
None yet
Development

No branches or pull requests

9 participants