winget-cli
winget-cli copied to clipboard
microsoft
Display the path to an installed package
Description of the new feature / enhancement
After installing a package using winget install <PACKAGE>, running winget show <PACKAGE> should also show the absolute path of the installed executable.
Proposed technical implementation details
winget show <PACKAGE> outputs several fields (like Version, Description, etc.) describing the package.
Another field Installed Path should also be added, that shows the absolute path of the installed executable.
I don’t know that this should be included in show, since show is used to display information from a manifest or other source. However, I could definitely see this being a useful option for winget list, if it were configurable through user settings and off by default
We have some work coming up to:
- #2252
For that feature, we are considering adding a path to main executable. That would likely help in this case.
I suggest that the subcommand should be called which, or at least that both which and show should be aliases for the same command. For example, that is how it is in Scoop, and that is how e.g., Linux does it with the which command. Having a show command alone would be counter-intuitive to already-existing users of other package managers, which is not ideal. Which (pun) is historically how binaries where located in Linux, and so I think that is the most appropriate name for the command.
This thread was the first hit when i went looking for a default install dir for winget. 📦 👍
I agree, I just installed winget install ntop and it took me ages to realize that winget had just thrown it into %LOCALAPPDATA%\Microsoft\WinGet\Packages\gsass1.NTop_Microsoft.Winget.Source_8wekyb3d8bbwe silently, without adding any PATH. Had to run an entire disk search.
There are some subtle behaviors here. I'll try to clarify them just to help everyone's understanding.
Use case 1: If you are in "Administrative" mode when you install, or if you have "Developer mode" enabled, WinGet creates a symbolic link in a common directory to the package.
Use case 2: If you are in "User" mode, then we have to add unique entries to the path per package.
In either case, the first time you install a portable package, the package will not immediately be available on the path. You will need to restart the terminal to be able to run the package.
For use case 1, after you have installed the first portable package and restarted the terminal, the path entry for the symbolic links is in place, so subsequent installations shouldn't require a terminal restart.
For use case 2, we have to add unique path entries, so each portable package will require a restart of the terminal to get the refereshed "Path" environment variable.
@danelon I did restart the Windows terminal. I even checked the PATH env manually, the program was still not there. I don't know if it's winget or the package author, but providing a way to manually investigate problems like this manually would be helpful
I ran winget install ntop in user mode in Windows Terminal (PowerShell).
I was given the message that I needed to restart my terminal.
I restarted and ran ntop.
If this isn't the behavior you're seeing (in user mode), please run winget --info and share the results, then run wignet install ntop --verbose-logs and share the results.
Do you have developer mode enabled or disabled?
@denelon I can confirm that after restarting Windows Terminal completely (not just closing the tab and opening a new one) it works as expected. Sorry I wasted your time and thanks for the help.
No worries. 😊 I know there are several subtle things impacting what we all want as the "best experience". I'm always open to digging in, troubleshooting and helping clarify what the product can and cannot do. The path environment variable has been one of the trickiest ones to deal with properly. I've put comments on several different issues attempting to clarify everything.
Honestly, I'm happy people care enough to complain and point out our weaknesses so we can help everyone fall into the "pit of success". I'm not shy about tackling hard problems, but there are always infinite wants and limited resources.
I just installed Python via WinGet, and am unable to easily tell where the executable was installed. Unlike ntop, it doesn't modify the path itself. Moreover, I have multiple Python versions installed, and having the path discoverable would be very useful to me. It seems a notable oversight that this piece of information is unavailable.
I believe a command-line tool should have command-line centric information (like the path) more readily available.
@MyrddinE I think implementing something like this would be quite complex considering winget allows the option to --override and many vendors include path parameters. In your example with Python, I actually do this for my users to ensure multiple versions play alongside each other. For example I will override and install to;
C:\ProgramData\Python\301 C:\ProgramData\Python\314 C:\ProgramData\Python\325
etc etc
google search brought me. I've just installed python via winget, and guess what, I have no idea where it was installed, and no way to find out without running a full disk search. timeline: 1998 - according to Wikipedia, first version of apt-get (the linux version) was released 2019 - "someone" decided to hijack AppGet (the open source Windows version). 2023 - still doesnt work.
if no location is provided as an argument, the installer uses its default logic and location - AKA its up to the installer where it put its files. For python its either a folder named Python# where # is the major version number if its a machine-wide install, or a folder in the user's AppData\Local\Programs if its a user-specific install
@Masamune3210 thank you for your help. I'm aware of this, and I was also able to find the location using file search. But as mentioned by others in this thread, and I agree with them, its not some "best experience" feature, its a "must have" feature for packages system.
@iksi4prs
What you are asking though is near impossible. Winget simple executes installer types. It's not the Msi engine. Inno types, exes don't always expose the "default" install path. So unless that default path is specified as a key in the manifest I doubt it's possible to do this reliably.
And adding this key to the manifest is extra "human" work required by the manifest maintainers.
Ie, this isn't a winget problem to solve, rather a fundamental problem with the myriad installer types for windows.
@cgerke I agree with you that "Ie, this isn't a winget problem to solve, rather a fundamental problem with the myriad installer types for windows.", and this is part of the problem. Instead of doing something the right way, out of laziness or some other reason, they took over (as in "hijacked") App-Get and give it the MS "stamp". As for "What you are asking though is near impossible." - when you work in the company the writes the code to the os, everything is possible. And even without it, if you hook CreateFile (using madCodeHook/Detours) in the spawn process, you can figure out the exact path. But why should people bother and volunteer to do this on their spare time, instead of MS employees ? We paid for this software. And last time I tried to commit to some Windows open source project, which was Wox, after few months I've found out it was hijacked into PowerToys under new name "Run".
I don't work for MS so politics aside, winget is useful to me managing deployments in a large enterprise (by myself).
Can I ask, regarding the path not being listed.
What problem are you trying to solve by knowing where apps get installed?
@cgerke "I don't work for MS so politics aside, winget is useful to me managing deployments in a large enterprise (by myself)." It was clear, I was just explaining. imagine how it would be more useful for you, if it didnt have appx 600 opened issues. As for "what problem are you trying to solve by knowing where apps get installed?" I had to run some bash script to do some complicated git maintenance, this bash was using py, and since as a dev I have 3 versions of py on my machine, I needed to explicitly select a certain py version for this.
Ok gotcha.
So thinking about this objectively, taking winget out of the picture...
What experience do you get when installing python through the GUI? At some point in the flow the GUI does ask you for a path, and that path is pre-filled.
However if you were to simply click next accepting all the defaults without looking, how would know the path? You'd be in exactly the same situation.
So my point is when doing silent installs that are exceptions to the rule, use overrides.
I do this for my devs to;
- allow multiple parallel versions
- avoid messing with their preset py libs
- avoid python org default installs breaking stuff (because you can't always rely on the vendors themselves packaging things correctly)
90% of all my scripted winget installs via Intune (almost 200) use overrides for this very reason as well as to use more verbose logging and to have greater control.
I got here while trying to figure out where cURL.cURL was installed. Issues with the existing system32/curl.exe always taking precedence over a scoop installed version aside, I ended up having to install Everything just to find the installation directory. Being able to find it through the package manager would be a nice improvement.
Speaking of improvements and Python, an equivalent to update-alternatives for Windows would vastly improve the developer experience.
@v1b1 I also ended up here trying to figure out where curl got installed :) For anyone else it was in:
\AppData\Local\Microsoft\WinGet\Packages\cURL.cURL_Microsoft.Winget.Source_8wekyb3d8bbwe\curl-7.88.0-win64-mingw\bin
sqlite.sqlite also is a ninja, it tells to restart terminal after installation, but restart doesn't help and it doesn't become available in PATH, and you have to google "winget show install location". Very unpleasant experience. (it was in %LOCALAPPDATA%\Microsoft\WinGet\Packages\). I doubt it were sqlite developers who chose a path of ~140 symbols to unzip 3 portable exe files.
I just installed xmlnotepad using winget and spent the following 30 minutes (truthfully it was longer than that, but I am not sure I wish to admit that as someone who is a professional Software Engineer with multiple decades of experience) looking for the binary!
The install gave me the option to update my path and I accepted, but it failed. I don't feel too ignorant that I couldn't locate the binary considering it is located at C:\Program Files\WindowsApps\43906ChrisLovett.XmlNotepad_2.9.0.0_neutral__hndwmj480pefj\Application\ and the installation log did not contain this path in it.
I remember a time when programs were located in two locations, very logical ones at that. "Program Files" or "Program Files (x86)". Then came a year when I can only assume it was a result of the fact that those two directories might not be writeable, and AppData began to see a lot of exe's deployed into it, which for someone like my father, would be an impossible place for him to find an exe considering the folder is hidden from users.
Without listing all of the other executable hiding places and reason my path variable exceeded the maximum allowed characters, requiring a third-party tool to cleanup, I will say that whatever approach Microsoft chooses to share such a location after installing packages with Winget, I would be another grateful person if this suggestion was implemented.
Also, it's really nice that I can just type a program name in the search box on my task bar and instantly see the installed xmlnotepad show up. Yet right clicking on the displayed program executable does not give users the option to see the installation path. Yet another usability feature belonging on another repository.
This situation is one where Microsoft is trying to dumb-down some details, but someone like my father would never be able to use a program that failed to create a desktop shortcut. He would call me and by the time we finished the call he'd probably go on computer strike for a couple months.
Jokes and my frustration tonight aside, I always try to say thank you for working on such a great tool. I really appreciate the ease of use, except this single case of anxiety inducing "where is it at"!
had the same need after installing FFMPEG package and didn't see the installation dir, and wasn't added to Path by default
had the same need after installing FFMPEG package and didn't see the installation dir, and wasn't added to Path by default
Exactly the same issue here. How there's no way to find the install location of apps is absolutely astonishing.
In reply to @cgerke above:
What problem are you trying to solve by knowing where apps get installed?
Some apps/packages do not publish themselves to the %PATH% variable. I need to know the path they have been installed to in order to use them. Else they are kind of useless.
Hoping this helps other users, I found these packages I installed:
-
C:\Program Files\WindowsApps\50760EliasAE.PlantUml_1.0.9.0_x64__em4zjwbm1gapy\Java\plantuml.jar -
%LOCALAPPDATA%\Microsoft\WinGet\Packages\ZakKemble.avr-gcc_Microsoft.Winget.Source_8wekyb3d8bbwe\avr-gcc-12.1.0-x64-windows
I don't know if people have noticed yet or not, but certain package types get installed in certain places usually by default unless the installer or the user overrides it. portable packages go in the winget source folder because where else would you put them, they don't have a specific location. MSIX get installed like any other MSIX. Anything else usually ends up in the Progfiles folders.
Things really arent that hard to find usually, I don't really think its that big of a deal
I love winget but my biggest issue with it is the default install location.
%LOCALAPPDATA%\Microsoft\WinGet\Packages\ is an awful location to put things. In addition, installers don't print the install location so you have to search your filesystem for the package you just installed (at least until you understand winget behaviour).
Thankfully, we can customise it with settings. I'd still like to see winget default install locations changed though.
