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

[denelon]

@voronoipotato thanks for the detailed feedback here.

We've been discussing several challenges associated with required environment variables like "path". We implemented support for path in the portable install flow, but we're still dependent on the package installers to handle this correctly today for other installer types. Part of the "upgrade" challenge is also associated with what type of an installer is actually being used.

MSIX packages upgrade natively (although there are still some bumpy experiences like upgrading winget by running winget upgrade "App Installer" -s msstore). For MSI "upgrades" we use the Product Code or the Upgrade Code to upgrade the "same" package. Traditional ".exe" based installers are essentially still much more challenging as they might do anything.

As there aren't graceful ways to deal with switching installer technology, we prompt the user when the installer type changes, and inform them that they need to uninstall the version on their system before installing the newer version. We've added keys to the manifest for "uninstallPrevious" when we know the earlier version should be removed, but in some cases, a side-by-side install is "by design".

We're adding extra metadata to manifest so we know what the "default" path and "default" program are. Something like that may lead us to a point where we could decorate a manifest such that we know the installer doesn't add the path, so we could inform the user that it's something they could/should do. Changing environment variables will still require a shell restart or a reload environment variables to actually function. That's likely something we would still want a user to actively do so we don't inadvertently break something else running on the system "at the same time".

[voronoipotato]

@denelon I'm going to talk a little bit about git, as a way of talking about strategy with installers. Git appears to have silent/unattended installation flags. https://github.com/git-for-windows/git/wiki/Silent-or-Unattended-Installation Does winget currently support the ability to use those? Or we could use the portable similar to how scoop does https://github.com/ScoopInstaller/Main/blob/master/bucket/git.json . It feels like critical packages have been broken for months or years, and that's really very bad for winget. If there's an incorrect way to do something, people will do it. If software that people rely on is provided in non-working condition, it will erode and eventually destroy winget. Nothing is more important than trust with a package manager.

I still have not "bought-in" to trusting winget, but the value it could provide if I can use it to quickly script installations on a developer's machine or server is incredibly obvious. If anyone doubts it, tell them to try Fedora or any other major Linux distro for a day where any software from any provider is available with ease. I can add external repositories from microsoft, dell, or anyone I want, as well as using a well curated list of packages that are certain to work well. It's something that I miss a lot every time I go to a windows server or my work computer.

[denelon]

Yes, today, WinGet uses the "known" installer types like inno, nullsoft, wix etc. as hints to determine things like installer switches for silent or "silent with progress" (our default mode). We also support switches for those modes when they are unique (this is very common with traditional .exe-based installers). They may also help with knowing how to do a "user" vs. a "machine wide" install.

For Git, winget install git.git --silent or winget install git.git -h should perform a silent installation without any output.

One of our critical goals early on was to meet developers (packages) where they are, and not to require them to be rewritten or to have to completely rewrite their installers. That does lead to challenges when the installer doesn't have parity in "silent" with what is supported via "interactive".

I see this as a bit of a "chicken and egg" challenge. We need a package manager as a bit of a forcing function to establish best practices. As you are stating, if the packages aren't ever "fixed", or the package manager can't reason about them, then it's a bad experience. We have taken the approach to assert rational "default" behaviors, and then extend with settings and arguments so the desired outcomes can be achieved. Today we have "--override" which allows overriding arguments WinGet defaults to with the manifest/installer type so users can specify the arguments they want. We also have an ask for an "augment" type of behavior so we can preserve the default switches and simply "add" to them.

[voronoipotato]

So can we provide those flags in the installer.yaml, or is that not implemented yet? For example with Git, it would allow the path to be provided in the default experience.

[denelon]

If there are arguments that set the path correctly, then yes, they could be added to the manifest. It may still require a restart of the shell or the environment variables to make it available. You can test locally with "-m ". In some cases, those arguments haven't worked when the install location was modified by the user.

[quazi-irfan]

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

On Windows 10, Neovim was installed on C:/Program Files/Neovim and the launch executable is C:/Program Files/Neovim/bin/nvim.exe. I had to restart the command prompt to be able to invoke nvim to start Neovim.

[Victor-N-Suadicani]

I just tried installing a package with winget. It was relatively easy to use winget search to find the package and winget install package similarly "just worked".

Then I got very sad when apparently it didn't "just work" and my package was seemingly not installed. It's not on the path, and since I have no idea where it got installed, it may as well just not have been installed at all.

This makes winget pretty much useless. Please prioritize this issue ASAP. Until this is fixed, I don't see any value in winget.

[denelon]

@Victor-N-Suadicani which package are you referring to? Can you share the WinGet logs?

[miklevin]

Just trying to install vim and git with winget. How is this so incredibly more difficult than on Linux? How do you figure out what path to add to Windows? And even once found, the process to add a path on Windows?!?! Ridiculous. Agreed, winget is useless.

[Victor-N-Suadicani]

@Victor-N-Suadicani which package are you referring to? Can you share the WinGet logs?

@denelon It was GnuWin32.Make in my case, but clearly it happens to many other packages as well.

[richtong]

I know right. :-(

Sent via Superhuman iOS ( @.*** )

[denelon]

It's up to the installer to add the package to the path (unless it's a portable package in the community repository).

[Masamune3210]

Is there a way to force PowerShell or whatever happens to be the terminal that is being used to grab a fresh environment block or at least a fresh copy of the path var? I'm assuming a lot of this comes from the fact that it never gets updated except for when its first launched

[denelon]

I've seen a couple of examples at Stack Overflow like: https://stackoverflow.com/questions/14381650/how-to-update-windows-powershell-session-environment-variables-from-registry

[Masamune3210]

That would probably be my next guess as the best way to handle this, since most people seem to just be confused why their portable program doesn't just magically immediately work after installation, maybe have it as the last step if winget knows that a path registration is needed

[Victor-N-Suadicani]

It's up to the installer to add the package to the path (unless it's a portable package in the community repository).

Why is winget different in this respect to practically all other package managers? Every user is going to expect winget to add the package executable to the path. Not doing that is tantamount to a bug, especially from the perspective of a user.

[denelon]

I assume you are comparing the Windows Package Manager against Linux package managers. There are some very subtle differences between Linux and Windows. The Windows registry and the various "public" and "private" APIs add a bunch of complexity (read constraints). There is a long history of building an "installer" for Windows whether it's a custom .exe-based installer, or MSI, and more recently MSIX. These are of various different quality. They also generate several different "classes" of behavior that we need to be able to reason about.

Given an arbitrary installer, there could be any number of behaviors it supports (or not). Some installers don't add the executable location to the path, and WinGet doesn't "know" this information beforehand. We also don't want to go down a path where we're writing branching logic for each version of any available package. That has led us to building a more robust manifest to deal with many of these variations.

We've been discussing the notion of refreshing the path (or any other environment variables) after install or upgrade, but we don't necessarily know which shell we're being executed in to know which variables to refresh. There are differences between cmd.exe and PowerShell so there is no "one size fits all" solution there. There are other shells that handle things differently so we wouldn't know what to do for them either. Even if we were to add a prompt to "refresh the path", it might not apply in all cases.

Best practices include building a better installer (which isn't viable in the short term for many organizations) and testing the experiences with WinGet. Different packages (publishers) make different assumptions about their users, so the advent of Windows having a package manager is still "new".

[BatmanAoD]

@denelon Upthread, there are comparisons against Scoop and Chocolatey, both of which are Windows package managers. They both solve the "add-to-path" problem, albeit in different ways. So there are two existing solutions in the Windows ecosystem.

[Masamune3210]

Scoop uses Junctions, and even chocolatey runs into the very same issue that winget is running into. Hacky solutions exist, but the hope is and should be to avoid them unless absolutely necessary

[voronoipotato]

If closing and reopening the shell worked that would be an outstanding improvement over the present situation . I can understand that these are difficult compromises, but if avoiding them means a completely broken experience, then I'd say your definition of "absolutely necessary" needs to be reevaluated. Scoop currently works, so I'd strongly disagree with your characterization of this as "the very same issue". This will unambiguously kill winget in the long term if this issue is not fixed. We all want winget to succeed, and we should not put our heads in the sand and pretend there aren't currently working solutions to this. We may not want to choose the existing solution, that's fine, but this project is broadly doomed without a solution. It's not great that windows is decades behind the competition in automation, and this is even more extreme for windows server where the need is even more important.

This is after I closed and reopened powershell. At the very least allow me to run the winget installed programs by doing winget run program , while I would be very unhappy with that as a solution it would at least allow it to be possible to use the things I've installed.