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 [[email protected]] - 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) https://github.com/microsoft/winget-cli/issues/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 - https://github.com/chocolatey-archive/chocolatey/issues/372
• January 2014 - Added to Scoop - https://github.com/lukesampson/scoop/commit/5c52166fcd813aaee0865e50f516b09d696bf9c7#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

[gitmpr]

workaround: After installing vim.vim with winget, the quick way to add it to path: right click start button, select run run the following command: systempropertiesadvanced go to Environment variables, select Path [Edit...] [New] C:\Program Files (x86)\Vim\vim82\

Since the vim version number is used in the directory name, you might have to find the location of newer vim versions by searching for it in the start menu: right click 'open file location' and adjust the path accordingly

restart the command prompt/windows terminal for it to take effect

[ricardo-j-sousa]

While that would surely work and the flow could be reduced to a PowerShell snippet I'm not sure about the manageability of adding hundreds of packages to the path (my workstation has a bit more than 110 packages, although not all should be in the global path). I should note that chocolatey, which I used previously, creates a «shim» exe in a global directory that is added once to the path.

That approach seemed to work well for me.

[a-gn]

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

The shims have the advantage of not needing to update every program's environment after installing a package. This would help us implement CI/CD pipelines with Winget.

[lucasjinreal]

SO, as a stupid user. how can I run nvim after I just runed winget install neovim extacly same as any unix system??

[m0rg]

lol.

[se316]

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

+1, I was delighted to learn that a Windows package manager exists but alas. The minimum expectations I have for a package manager are:

• Be able to search a repository for different packages.
• Be able to install , update or uninstall those packages.
• Have those packages be immediately callable after installation.

The third point is what I did not see after installing Vim. Since I am only installing a single package it is feasible to manually add it to path but winget still has a ways to go as a go-to resource.

I do think it is the role of the package manager to add installed packages to path automatically and like this suggestion if it's compatible with the other points

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?

Appreciate the hard work on this and looking forward to seeing winget reach its potential! Just throwing in my two cents to show that this is a looked-for feature and there is community interest in winget.

[voronoipotato]

I'm very frustrated

Winget is shockingly close to being one of the most valuable programs on windows. However If a console program can't be called after installing it, it should not be included in the packages. Winget is a terminal command, and the things it installs should also be accessible. If I can install console programs programmatically and can't use those programs programmatically it really has no value in any sense. This is bundled with the paid product Microsoft Windows™ and provides critical functionality that prior Windows™ desperately lacks. I was embarrassed at work when I told coworkers about winget. Even git didn't work and I have no clue how to make it work.

• I found the product backlog (thank you @denelon), why is this on the backlog? I can't find a single issue on the currently being worked list that I care more about than this issue. For me winget works fine, it just isn't usable for anything of value yet.
• Why is it not a priority? This can be done, other windows package managers currently do it.
• Where did git get installed and how do I find it? (I normally wouldn't even care, but it's not in my path, so I need to add it to the path somehow)
• If its a manpower problem can we please hire more people to work on it? I think winget OUGHT to be installed by default, as it's critical infrastructure, but it should also work.

[voronoipotato]

Hello @denelon , trying to give winget a second chance. I thought well maybe it's not really for terminal programs. I hit a similar (less impactful) issue again today where I followed the guide at https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell?view=powershell-7.3 where I ran winget install --id Microsoft.Powershell --source winget and it installed... but initially I couldn't find it at all. I was able to find it by searching for powershell, as "powershell 7".

I'm not used to new versions installing as separate programs. Typically when I install a program it actually replaces the older version unless otherwise specified. If I use winget to provision machines, people are going to run the old old version of powershell that is still there because the old version comes up first in the search. When I call the powershell command, it still calls the old powershell. It feels like the team isn't dogfooding winget to provision their machines, because this tool is missing very simple and very critical comforts.

Normally I would make a new issue for something like this, but I'm afraid you would prioritize it over fixing the paths issue, and if that's the case I don't want this fixed. I would pay a fair bit of money to stop all other issues until this issue is fixed since it severely limits the default windows experience especially compared to the competition.

[Masamune3210]

It's not a issue with WinGet, that's how PowerShell is handled even if you manually use the installer. They are installed as separate programs because the version from GitHub can't replace the system version without being handled in special ways. Having it as a separate program allows for faster upgrades and other things that would normally have to be locked behind the normal update cadence

[voronoipotato]

Alright, thanks @Masamune3210 . I think that's a really dumb decision by msft that it's not possible to update powershell but also clearly not winget's fault here.

As an aside, that I guess I'll have to bring up in the powershell repo? I get that Microsoft might need a fixed version of powershell behind the scenes but I feel like bare minimum I should be able to update powershell for user space, where when I call powershell it uses the newest powershell, and the shortcut for the old old powershell no longer shows up... It's just bad UX. It gives the impression that it didn't work, since you open powershell and it's still old. Call the powershell command, still old.