Repository navigation
Enable loading of Feedback providers via config #25115
Description
Summary of the new feature / enhancement
Some native commands may want to participate by providing a Feedback provider, but not want to craft a whole module just for it. Tools today modify the user's $profile during app install and can be tricky to remove correctly during uninstall.
Proposed technical implementation details (optional)
Extend powershell.config.json to have a section for Feedback providers. Essentially containing this section:
(actual implementation will be in JSON, using YAML for readability)
FeedbackProviders:
- Name: WinGet CommandNotFound
Path: $env:programfiles\foo\bar.dll
Enabled: trueThe system config.json would be the default and users can override with their own config.json (setting Enabled: false).
Feedback providers loaded on startup via this method would need to have some message shown to inform the user.
One problem is that new installs of PS7 have a default system config.json which would clobber the old one. Perhaps instead we should have the system one under ProgramData (on Windows) which would be the one apps can modify for install/uninstall.
Activity
SteveL-MSFT commentedon Mar 2, 2025
cc Steven Bucher (@StevenBucher98) , Dongbo Wang (@daxian-dbw)
rhubarb-geek-nz commentedon Mar 3, 2025
This is a generally problematic approach of having multiple different installers modifying files that other tools have changed. When does a tools add to the file, when does it remove from the file, how does it know what it has to remove.
In the UNIX world this problem has been addressed by having directories with the ".d" suffix so installers add and remove atomic files without interfering with others. ( eg /etc/rsyslog.d, /etc/apt/apt.conf.d etc)
PowerShell already has a mechanism to do this, scoped by user or system; PowerShell modules.
There is no problem with a native command's MSI also installing files in
%ProgramFiles%\PowerShell\7\Modules\...or an RPM adding files to/opt/microsoft/powershell/7/Modules/....An MSIX or snap can't do this because they are self-contained directories, but then neither could they install other configuration files.
daxian-dbw commentedon Mar 3, 2025
Asking each tool to update a config.json file -- would that be the same as asking tools to update the profile? All tools still need to change a file to add/remove a section, and they will need to get permission from user first before doing it because no one wants the PowerShell startup suddenly slows down without knowing why (I installed
minicondaon my personal computer recently which adds aallUsersprofile that slows down PowerShell startup. It took me sometime to figure out why PS suddenly slows down).Ideally, the loading of a feedback provider should be lazy, which only happens when the native command run fails. I like the directory mechanism used on Linux better but need to think about how to use that for feedback provider loading.
iSazonov commentedon Mar 3, 2025
Why really invent something if there is already a module mechanism? All you need is a contract on how to find them (by specific name format or a flag in manifest) and download them automatically at the right time.
SteveL-MSFT commentedon Mar 3, 2025
Updating a json file (which is structured) isn't the same as adding/removing lines from
$profilewhich is a script.Ilya (@iSazonov) , rhubarb-geek-nz the intent is to enable apps/tools that DON'T have a PowerShell module, they are native commands that want PowerShell integration. We have some partners asking for this, so this isn't a hypothetical situation.
The directory mechanism means you would still need some config for the user to indicate they DON'T want auto-loading of some extensions.
rhubarb-geek-nz commentedon Mar 3, 2025
How is the native tool packaged?
If it is an MSI it can provide a psd1 file and a psm1 file in %ProgramFiles%\PowerShell\7\Modules\Contoso.SuperDooperApp.
That would be less work than adding additional scripting within an MSI that changes a json file and abides by all the MSI roll-back rules.
In what other manner are you expecting the json file to be updated?
iSazonov commentedon Mar 4, 2025
Thanks for clarify! Although there is still little information to understand their request. When I think of a native app, I imagine that it uses the SDK. Then why bother with the config at all - rather, you need a public API to discover and manage the providers. In this case, if the config is needed, then the application itself, but not for pwsh.
rhubarb-geek-nz commentedon Mar 4, 2025
Can you give some examples of what you mean by native app? It can mean anything.
Do you mean C/C++/Rust apps? Console or GUI? Installed from AppStore or MSI?
Are you wanting a solution that works on all platforms, or only Windows?
Is it supposed to be completely seamless or should the user do anything additional?
What happens when PowerShell 7 is not installed, and then it is installed after the native app?
What installation methods of PowerShell should be supported, eg from zip, msi, appstore, msix, homebrew, snap etc?
Given the installation base, does the mechanism have to work with PowerShell Desktop?
Why not have a public github project and PSGallery module containing feedback providers for common command line apps, then simply ask the app developers to contribute to that rather than providing the additional resources in their app that won't be used by 99% of their installed base?
daxian-dbw commentedon Mar 6, 2025
The directory mechanism doesn't necessarily require a module to be present. The configuration in the directory of a specific tool just need to indicate where to find the provider -- it could be from a module, or from an assembly (which may just be deployed in that directory).
No matter it's the PowerShell config file or the directory mechanism, the installation always needs to get permission from user before making the change. For the directory approach, we can define a key in the configuration of each directory to control whether it's disabled. The benefits of the directory mechanism are:
daxian-dbw commentedon Mar 19, 2025
Steve Lee (@SteveL-MSFT) I submitted a draft spec for auto-discovering feedback providers and tab-completers: PowerShell/PowerShell-RFC#386
theJasonHelmick commentedon May 14, 2025
Thank you Steve Lee (@SteveL-MSFT) for this issue. The WG interactive has reviewed this and prefers the alternative mini-spec from Dongbo Wang (@daxian-dbw) and would like to see that move forward. spec: PowerShell/PowerShell-RFC#386
microsoft-github-policy-service commentedon May 16, 2025
This issue has been marked as declined and has not had any activity for 1 day. It has been closed for housekeeping purposes.
microsoft-github-policy-service commentedon May 16, 2025
📣 Hey @Steve Lee (@SteveL-MSFT), how did we do? We would love to hear your feedback with the link below! 🗣️
🔗 https://aka.ms/PSRepoFeedback