Installing a package doesn't add it it to path

[matifali]

Brief description of your issue

Installing a package doesn't add it it to path

Steps to reproduce

1. Install Vim using
   winget install Vim
2. Try to run it using
   Vim test.txt

Expected behavior

Vim should open the file if it exist or create a new file.

Actual behavior

Vim : The term 'Vim' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included,
verify that the path is correct and try again.
At line:1 char:1
+ Vim .\test.txt
+ ~~~
    + CategoryInfo          : ObjectNotFound: (Vim:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Environment

Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19041.450
Package: Microsoft.DesktopAppInstaller v1.10.42241.0

[yigitemres]

As I know, winget don't add to PATH automatically. But if the installer itself have ability to add its exe to PATH that means Switches have problem. I'm gonna look at it.

---

I'm look at it and vim installer don't have any installer arguments (and there is no installer option to add PATH too). You have to add yourself until this ability comes to winget. There is some feature requests about this issue. It's gonna be added.

Have a nice day! 🥂

[matifali]

Thanks, I came from linux and is used to installing packages with apt command. So I was expecting the same behaviour with winget.

[yigitemres]

I think that linux users benefits WSL as a package manager when native gui server comes with it. I use WSLGentoo and when gui server comes with it, I will migrate fully and only use winget in order to contribute it.

[mhm13dev]

@matifali winget is still in preview. Hope it will soon grow like apt and other package managers. We have to wait.

[denelon]

I've been working on the backlog recently. You can take a look at the milestones to see what we're planning.

We do plan on having the ability to add the path for .zip, .exe, and standalone/portable apps. I'm not sure what we'd be able to do with an installer that doesn't provide a path. If we specify a path during "install" time for packages like this, we might be able to add that path to the environment. Is that what you would be looking for here?

[mhm13dev]

@matifali this path problem is not because of winget-cli.

The actual installer of vim does not add vim directory to the path. So this is not an issue of winget-cli.

[yigitemres]

I've been working on the backlog recently. You can take a look at the milestones to see what we're planning.

We do plan on having the ability to add the path for .zip, .exe, and standalone/portable apps. I'm not sure what we'd be able to do with an installer that doesn't provide a path. If we specify a path during "install" time for packages like this, we might be able to add that path to the environment. Is that what you would be looking for here?

@denelon I don't know how you gonna handle this but something like this will be good I think:

1. Determine or override default installer location.
   1. Either pass location: variable as keyword to all manfiests files and install them under "..\winget-pkgs\$pgkname" to easily find winget-pkgs.
   2. Or pass default installer location as location: keyword.
2. Add shortcut: keyword to manifests.
3. Add createshortcut: keyword (can be overridden with winget install vim --shortcut y|n )
4. Run script and add environ vars under winget-shortcuts name with powershell script after each successful installation according to location and shortcuts from manifests. (I don't know how to create environ vars from powershell and I'm too lazy to right now to find it. 😆)

In the end it turns something like this (example for vim manifest):

Id: vim.vim
Name: vim
AppMoniker: vim
Version: 8.2.1484
Publisher: vim
Author: vim
License: Copyright (C) 1991-2020 Bram Moolenaar [Bram@vim.org] - Charityware / GNU GPL compatible
LicenseUrl: https://github.com/vim/vim/blob/master/LICENSE
MinOSVersion: 10.0.0.0
Homepage: http://www.vim.org/
Description: Vim is a highly configurable text editor built to make creating and changing any kind of text very efficient
Tags: "vim,gvim,vi,text editor,text editing,code editor,utility,tool"
InstallerType: nullsoft
Installers:
  - Arch: x64
    Url: https://github.com/vim/vim-win32-installer/releases/download/v8.2.1484/gvim_8.2.1484_x64_signed.exe
    Sha256: 02c7e62b4c712af927d2f0a9635ca7746072feab81b6071a00d95dea2a4ec654
    Switches:
      Silent: /S
      SilentWithProgress: /S
    Location: "C:\Program Files\Vim\vim82" # Default install location.
    Shortcuts: "vim.exe, gvim.exe"
    CreateShortcut: y

[pennstatephil]

Is this essentially a duplicate of #222 ?

[atniomn]

This isn't an exact duplicate, because opening a new shell doesn't change the behavior. the Application is still not in the PATH.

[pennstatephil]

This isn't an exact duplicate, because opening a new shell doesn't change the behavior. the Application is still not in the PATH.

Makes sense-- it does not appear to be a problem with winget, but with the vim package; I guess the question then becomes how should winget handle packages that don't add themselves to PATH? Is this exclusive to the vim package, or have other packages shown this behavior too?

[Witchilich]

Rather than populate your PATH like Chocolatey, winget should add shims like Scoop(UWP also has this feature)
#361

[matifali]

@matifali this path problem is not because of winget-cli.

The actual installer of vim does not add vim directory to the path. So this is not an issue of winget-cli.

Yes I understand But wiget-cli should not accept such packages in repo if they don't add themselves to path.

[doctordns]

Is there any due diligence performed on the items in the winget repos? Does Microsoft do any validation of applications??

[matifali]

Is there any due diligence performed on the items in the winget repos? Does Microsoft do any validation of applications??

Most probably no.

[ferventcoder]

Rather than populate your PATH like Chocolatey, winget should add shims like Scoop(UWP also has this feature)

@Witchilich Sorry to jump in. 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 might 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

[quangkieu]

I think windows already has its own version shim, if you look up wsl.exe, wt.exe. they are in windowsapp folder

[richtong]

So I’m a complete idiot. How can you figure out where vim actually installs. I’ve tried winget list vim and can’t figure it out. Do I look at the source. Same issue with winget install git by the way.

[manmartgarc]

Is this still pending? Does anybody know a workaround? edit*: regarding vim

[ericchansen]

Being able to easily install vim with winget should be a core use case of winget.

[loopervfx]

I just tried winget for the first time on a brand new windows 11 system from dell and encountered this.

• entered winget install whois ,
• then restarted terminal / powershell,
• entered whois and received whois : The term 'whois' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

This is completely unacceptable and an absolute non-starter for a package manager. this is the application level equivalent of installing an operating system without adding it to the bootloader. fixing this should be priority 1. thank you

[se316]

This issue's been open for 3 years and I get emails for this thread frequently. The conversation keeps going in circles about how it's not the role of the package MANAGER to manage the dang package! This is far from true of EVERY other package manager I have ever used for any system or language, ever. I have never had to go hunt things down after they were "installed" because they've always worked as expected. The only one that's not in line here is winget, and it makes me think about POLA (Principle of least astonishment).

In user interface design and software design,[1] the principle of least astonishment (POLA), also known as principle of least surprise,[a] proposes that a component of a system should behave in a way that most users will expect it to behave, and therefore not astonish or surprise users. The following is a corollary of the principle: "If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature."[4]

see also

For those parts of the system which cannot be adjusted to the peculiarities of the user, the designers of a systems programming language should obey the “Law of Least Astonishment.” In short, this law states that every construct in the system should behave exactly as its syntax suggests. Widely accepted conventions should be followed whenever possible, and exceptions to previously established rules of the language should be minimal.

I know this isn't actual law, but having to play find the needle in the haystack with software I got through winget isn't what I expect from a package manager - the package manager is supposed to let me pick a package from a repository, install it, and be able to use it after install. Winget does 2/3 of those things. As a user, I couldn't really care less how this is handled semantically; I just want those programs to be callable! Not a single thing I have ever installed through winget has been callable after install even if I opened up a new shell. I've had to look for Every package and add them all to path myself, --info is supposed to show me install locations, among other things, and I'm not even seeing my package in those directories, --location is supposed to let me at least pick the location the package is installed to and that didn't work for me! So now here I am, having to play find the needle in the haystack with ffmpeg and thinking about POLA, and this specific Issue.

The thing I really admire about technology is that there's never only one perfect way to solve an issue, there are always multiple options that can be used to achieve a given goal. This is true on both ends, you have multiple options you can try to work with, and I have other package managers I could try that work as expected. I'd rather have SOMETHING that's good, than wait around forever for something to be perfect. I don't need perfect, and no one here is asking for perfect or really even being too picky about the implementation.

Anecdotally, I'm using a different computer and the Chocolatey package manager was FAST to install, it installed ffmpeg quickly for me, and I didn't even have to start a new session to call it. This is a package manager working as expected, this is the kind of result I want to see. Chocolatey used a shim, I do not care that they used a shim, they didn't get bogged down with the semantics like we're seeing here they just did Something! Seeing how fast and simple Chocolatey was to setup/use, I don't really see myself coming back to winget and am just going to put Chocolatey on all my home and work systems for future use, and if asked about a good Windows package manager that'd likely be my go-to because yeah if I'm being honest with them and knowing what they expect from a package manager why would I, or anyone, recommend winget over anything else that does what people expect a package manager to do.

I want to be sympathetic here, but every time this Issue looks like it's going in the right direction and we landed on SOMETHING to try, it gets steered back to the position that winget is not responsible for making things callable after install - and that this is the job of the package maintainers themselves. I don't really have the energy to care about this anymore given I found a good solution, but figured this feedback is important to share nonetheless. There is a lot of valuable user feedback and genuine good faith attempts at trying to find a solution in this thread that is not being fully appreciated and these people are working with you for free and unsolicited because they want this to succeed. I do too, but I can't really wait for it and I'm definitely not going to argue for it when Chocolatey is right there.

---

Three separate things that would probably make this whole situation more workable for end users, besides actually addressing the problem in question, would be 1.) show people WHERE any given package is getting installed so if it's not callable afterwards we at least know where to look exactly so we can fix it ourselves 2.) don't call winget a package "manager" if it can't fully commit to being one, can't complain or compare it to a PM if it's not trying to be one, or 3.) fully lean into it being on package maintainers to ensure a portable/MSIX version of their package is added to the repo for predictable outcomes, and in doing so tighten your standards on what it takes for a package to be listed in the repo.

---

After having gone through the entire thread I'm assuming every single program I've ever tried downloading through winget wasn't portable and led to them all ending up in random locations and giving me an extremely poor UX. The poorest package management UX I've ever had to date!

Also not helping with the overall reception here is it's not clear who on this thread is actually a winget dev and who is just playing devil's advocate and speaking for/over winget devs (or defending MS) - neither of which they have to do because everyone who is raising this as a concern wants to see a built-in Windows package manager that's on-par with any other run-of-the-mill package manager.

Yes, Linux-based ones will be mentioned because they're the most immediately recognizable - but you also have working Windows-based ones being mentioned by name because people want it to work! Pedantry isn't productive and if you're not actually on the dev team are just drawing more ire towards them, lack of visibility into what's actually happening with this Issue doesn't help, and as an end user my trust and interest in this product is pretty burnt :^} this exact Issue IS a really big deal and IS a major expectation of anyone who has used a package manager before, regardless of what's being argued here. winget is the outlier full stop.

This is a very real example of someone who leads the IT/*Admin team at an organization falling out of this because of all the friction and inconsistency that goes into trying to use it, as has been warned about multiple times throughout the thread. I am validating those people and saying they are right.

[doctordns]

A long response but while the POLA is an interesting justification, Snover's First Law trumps it. To ship is to choose and in 3 years the Winget team has indicated no interest in implementing this, and almost zero support elsewhere. And o see zero interest from those who could implement it. In my experience guilt tripping rarely works.

But if you want it, then explain how it could be implemented. I know of no way running an executable in PowerShell that can cause the environment block refreshed (and $profile to be reexecuted). And even if it could be, it would seem to be a security hole.

I see little hope of winget doing this on its own. You would need to change PowerShell and Windows Powershell. And I see zero chance of updating powershell to implement this (and an even lower chance of backporting it to Windows PowerShell. I could be wrong, but I simply see inadequate support.

[safakgur]

I know of no way running an executable in PowerShell that can cause the environment block refreshed (and $profile to be reexecuted). And even if it could be, it would seem to be a security hole.

I don't know why we keep going back to this. I understand how the issue's title could give the initial impression that winget needs to add stuff to PATH, but if you read their full message, the only thing OP wants is the following to work:

winget install vim
vim test.txt

And this behaviour can be achieved using shims. scoop does it today. It is not some novel problem that we have to rewrite the OS from scratch to fix.

So, please stop bloating the thread about why something we never needed in the first place can't be done.

---

When I don't care about a feature, I just ignore the GH issue suggesting it, because why not have it if it will be useful to someone, right? That is unless it would introduce some undesirable behaviour that I rather not see in the product. Does winget implementing this feature have any downsides you're worried about that we are not aware of? Would it negatively affect how you use winget in any way whatsoever? And if not, what value are you trying to add here?

"I've been using Windows before you were born, and I never needed it" isn't an argument against this feature - the only thing it tells is that there are people who can live without it, and don't get me wrong, that still is valuable feedback, but does it really need to be repeated under every message that justifies this feature? We heard your opinion about why you don't need this, but we all have different needs.

[rickdgray]

@denelon Is there any movement or interest in this issue?

[voronoipotato]

@doctordns You could argue every issue in every repo is not possible because you do not know how to do it. Your own lack of knowledge is not a counter argument. You have ignored all the approaches already proposed in this thread. Either educate yourself on why this is possible, feasible, currently in use, and make more nuanced critique of a specific approach or stop spamming this thread. There was support by @denelon a few months ago when we workshopped some ideas. It is on the vnext-client backlog for a reason. If we can instead use this issue for discussion upsides/downsides of specific approaches and get affirmation around which path the lead wants to go we can start actually implementing it. I personally think shims are the way to go because they're really easy to write but I'd be curious what the lead's take is.

[jazzdelightsme]

@doctordns: it's true that there's not a great way for a separate process (winget.exe) to modify the environment block of a parent powershell.exe process, but as alluded to in several places on this Issue, there are other ways to deal with the problem. In particular, I proposed a solution in this comment, including a concrete list of design constraints which led me to that solution, and actual code you could put on your system to try it out.

(It's totally understandable that one could miss that comment; this Issue is huge, and I had to click through multiple "show hidden items" folds in order to find that comment again.)

I took the liberty of making my idea easier to consume by publishing it as, you guessed it, a winget package. :D

It requires admin access to install, which is unfortunate, but even so I think it could make things a lot more convenient for a lot of people, so I went ahead with it. You can try it out by:

winget install WingetPathUpdater # <-- this is the thing

# Now this will work:
winget install nvim
winget install Microsoft.VCRedist.2015+.x64  # this is missing from the nvim package :(
nvim  # ta-da!

(that is for pwsh, but it also works for cmd; just don't paste the # comments, of course)

(More info here: https://github.com/jazzdelightsme/WingetPathUpdater)

My package is not an ideal solution. Besides requiring admin, you have to know that you need it--having a solution in package form does not help unless you have the package, and I expect most people will not know that they need this package.

Just to head off the conversation "why doesn't winget just ship this 'in-box'?!": the winget team has more constraints than I do (see caveat at the beginning of my Design comment), so I doubt they would find it feasible. However, they are aware of this package's technique (and I know they carefully read and discussed my Design comment), so hopefully it is helpful to them. And I hope my package is helpful to people in the meantime.

Edit: oh, and special thanks to @denelon and @stephengillie for helping me get my package manifest working!

Edit 2: Oh crud; my first demo used "winget install vim.vim"... but I had tested on a not-clean system. It turns out that the problem with the vim.vim package is that it does not update PATH at all--even opening a new console window does not help. Sigh. So I updated the demo to use nvim.

Edit 3: on a totally clean VM, nvim "launched", but didn't really run: it depends on the VC runtime, but doesn't distribute it (installer bug, IMO). So I added "winget install Microsoft.VCRedist.2015+.x64" to the demo.

[denelon]

It requires admin access to install, which is unfortunate, but even so I think it could make things a lot more convenient for a lot of people, so I went ahead with it. You can try it out by:

winget install WingetPathUpdater # <-- this is the thing

# Now this will work:
winget install nvim
winget install Microsoft.VCRedist.2015+.x64  # this is missing from the nvim package :(
nvim  # ta-da!

We're working to get dependencies out with WinGet 1.6 (ETA end of September). A couple of weeks after that we will start automated validation with dependencies in earnest.

• Support for package dependencies #163

Updated: WinGet 1.6 supports dependencies.
With the latest version of WinGet you should be able to:

> winget install WingetPathUpdater # <-- this is the thing
> winget install nvim
> nvim

[voronoipotato]

This is awesome!! thanks @jazzdelightsme for your hard work and thank you @denelon for supporting this. Very exciting :)

[martinemdal]

Running:

winget install WingetPathUpdater

broke my winget digital signature. Would rather not change my execution policy to install vim.

Ok, not 100% sure what I am doing here. Need to fiddle around with it a bit more. WingetPathUpdater seems to install a winget.ps1 that is not digitally signed. But after unistalling it, I still have my old signed winget executable.

[mon-jai]

If you have problem installing global commands from pip, try adding the following directory to your PATH.

%LocalAppData%\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\Scripts

[fn5]

@mon-jai
This issue is not specific to packages which execute global commands to pip.
I have had this issue with a number of packages. WingetPathUpdater does present good information and a possible solution (https://github.com/jazzdelightsme/WingetPathUpdater#readme), however IMO a solution does not exist yet for this issue.

Even some kind of prompt would be helpful - "Warning: this package will not executable using its alias [alias] until the shell is restarted." I would note this includes any shells that may be open within VS Code etc.

[soredake]

Stumbled upon this package that have cli version but installer does not add it to PATH https://github.com/microsoft/winget-pkgs/tree/afaf1950df18389dcf43dcdb43e9c5673f58fce0/manifests/p/PragmaTwice/proxinject

Same with 7zip-zstd mcmilk/7-Zip-zstd#360

[soredake]

#4008

[denelon]

Great news!

https://blogs.windows.com/windows-insider/2024/02/14/announcing-windows-11-insider-preview-build-26058-canary-and-dev-channels/

Search for "winget" on that page.

[Command Prompt]
If you run winget, or any other package manager configured to do so, Command Prompt (CMD) will now look for changes to the PATH and update your current session. To enable a package manager to have this logic in CMD, simply add the package manager .exe name to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\KnownPackageManagers.

Note: This has not been implemented in PowerShell.

[rickdgray]

Amazing!!

[billwert]

Note: This has not been implemented in PowerShell.

but.. will it? :D

[sohang3112]

@denelon This is indeed good news, but many programs don't add themselves to the PATH at all - we still need a solution for these (expecting all programs to remember to do this isn't realistic).

[MatthewHannigan]

In the meantime, use the --interactive flag and click the .bat file checkbox per microsoft/winget-pkgs#656 (comment)

winget install --id vim.vim --interactive

[jefer94]

It isn't refreshing my shell after the installation, also in vscode if I don't close those windows the shell isn't refreshed inside it.