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

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

[theJasonHelmick]

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.

The PowerShell team has spec'd this change and is evaluating with impacted teams. I don't have a date to announce, but we plan to include this in the future.

[eggbean]

I made this PowerShell script for solving the path problem when using winget to install. It makes a persistent symlink so that I don't have to change my vim path in my git config.

https://gist.github.com/eggbean/351982f02f0ce7203669ac5ee05d7a06

[voronoipotato]

@denelon we're still experiencing it for Godot even when we close terminal entirely and reboot any tips?