Draft spec for auto-discovering feedback provider and tab-completer

[daxian-dbw]

This is a draft spec for auto-discovering feedback provider and tab-completer. Relevant GitHub issues:

• Enable loading of Feedback providers via config
• Add a way to lazily autoload argument completers

[StevenBucher98]

Should we consider predictors in this set of supported auto discoverable "things"?

[StevenBucher98]

For example the completion predictor may be good to auto register since it doesnt really have any commands

[daxian-dbw]

There won't be a specific trigger for any predictor, so if needed, a predictor module can just be placed under the _startup_ folder of Feedbacks or Completions.

Think about it more, I guess we may want to unify the _startup_ folders from feedbacks and completions, since they all will be loaded at startup. Maybe we should have a startup folder at the same level of feedbacks and completions, so any predictor/feedback provider/tab-completer that needs to be loaded at session startup can be put there.

[StevenBucher98]

Is this going to be affected by the One-Drive issue?

[StevenBucher98]

I think this could be good, thinking about the linux cmd-not-found predictor. Also if a user wants to bring this configuration across their different machines they dont need to have multiple different folder structures? I am not entirely sure how they would necessarily do it but I know some community folks use external tools to share their $PROFILE across machines.

[daxian-dbw]

they dont need to have multiple different folder structures?

Folder structures under feedbacks and completions are the same. I guess a user can create a symbolic link to make <personal>/powershell/feedbacks or <personal>/powershell/completions points to the folders from a cloud drive.

[StevenBucher98]

Is. there a reason why this all can't be in a single json file? i.e feedbackproviders.json?

[daxian-dbw]

Tool installation needs to easily deploy/remove the auto-discovery configuration. We want to avoid updating a single file to make that easy.

[iSazonov]

I see the key elements here - autodiscover, autoload, and trigger.
All this is already available in PowerShell modules.
Why not just adapt the existing mechanism to meet new needs?

One option was suggested by me a few years ago PowerShell/PowerShell#13428
This allows us to load any necessary extensions for native commands.

For example, if we introduce a naming standard, we can put Native-dotnet in any module and the engine (NativeCommandProcessor) will trigger finding this module and load, for example, an assembly/script with completer for dotnet command.
(If we have to strictly follow the existing naming rules for cmdlets, then the name could be Get-NativeCommand<name>- Get-NativeCommanddotnet)

If we need a CommandNotFound feedback provider for WinGet, we can agree that we are looking for a module with a name like FeedbackProviderWinGet where FeedbackProvider is a search key for the scenario.

Everything for modules is familiar and understandable to users and it can be implemented in small steps.

[SteveL-MSFT]

This will make it not possible for an Appx app to participate since they can't place files outside of their own installed folder

[daxian-dbw]

I mentioned Appx and MSIX packages in the "Discussion Points" below. I think for those apps:

• If they want to provide tab-completer, then the tab-completer needs to be exposed by running the tool with a special flag, such as <tool> --ps-completion, then the user can manually create the "deployment+configuration" for the tool using the output script. Or, even better, the user can just run the output script, which will create the deployment automatically.
• If they want to provide feedback provider, I'm not sure how that will be possible. According to Add a way to lazily autoload argument completers PowerShell#17283 (comment), the tool's DLL should not be used by another process, but feedback provider and predictor are binary implementation only.