New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help System as a standalone PowerShell Module #102

Open
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
8 participants
@adityapatwardhan
Member

adityapatwardhan commented Jul 27, 2017

This RFC proposes making HelpSystem as a standalone PowerShell module and remove it from System.Management.Automation.dll.


This change is Reviewable

Help system is used predominantly in interactive sessions and hence not required for automation scenarios.
Since, it is part of System.Management.Automation.dll it is always loaded with PowerShell.
Help system is sizeable piece of code, which increases the runtime footprint of the process.
This RFC proposes to make the help system a PowerShell module, so it is loaded only when used.

This comment has been minimized.

@iSazonov

iSazonov Aug 3, 2017

Contributor

We could add HelpSystem abstract class to allow customers to implement help system themselves.

This comment has been minimized.

@adityapatwardhan

adityapatwardhan Aug 3, 2017

Member

I intend to implement a plugin model. Since that is implementation detail, I did not include it in here.

This comment has been minimized.

@SteveL-MSFT

SteveL-MSFT Aug 4, 2017

Member

If you have thoughts on public api's, I think it's worth including here or note that it'll be in a separate RFC

This comment has been minimized.

@iSazonov

iSazonov Aug 4, 2017

Contributor

It make sense to write this explicitly that users can implement custom Help system module based on new public API..

This comment has been minimized.

@adityapatwardhan

adityapatwardhan Sep 19, 2017

Member

I will update this to specific the new public APIs.

This comment has been minimized.

@iSazonov

iSazonov Jan 25, 2018

Contributor

If the intention is to make a plugin model will this root code in the engine? I would see all help root code in a separate module, and plugins in other modules.

| UpdatableHelpCommandBase | Used by UpdateHelpCommand, breaking change impact is medium.
| UpdateHelpCommand | Sealed class, breaking change impact is low.

[CLR Type Forwarding](https://docs.microsoft.com/en-us/dotnet/framework/app-domains/type-forwarding-in-the-common-language-runtime) will be considered to lessen the impact of the breaking change.

This comment has been minimized.

@iSazonov

iSazonov Aug 3, 2017

Contributor

I think we should state this as main solution.

This comment has been minimized.

@adityapatwardhan

adityapatwardhan Aug 3, 2017

Member

I will mostly likely be used. I still need to investigate the impact if the forwarded type is not found, for example Microsoft.PowerShell.HelpSystem module is removed.

This comment has been minimized.

@adityapatwardhan

adityapatwardhan Sep 19, 2017

Member

Actually, this might not be feasible as type forwarding only works if the namespace is same.

This comment has been minimized.

@iSazonov

iSazonov Sep 20, 2017

Contributor

We could place mandatory types in mandatory assembly (maybe leave in SMA) and any extentions put in optional assemblies (and maybe another namespace).
HelpSystem is based on help providers so we could consider to make the help providers as optional and loadable.

@vors

This comment has been minimized.

Contributor

vors commented Aug 23, 2017

This is great, love it

@adityapatwardhan adityapatwardhan force-pushed the adityapatwardhan:HelpSystemModule branch from 7da9286 to 1a682e4 Apr 2, 2018

@joeyaiello

This comment has been minimized.

Member

joeyaiello commented Apr 4, 2018

@PowerShell/powershell-committee has decided to take this into the experimental folder so that we can begin prototyping/implementing without blocking on a vote.

I personally want to follow up on the CLR type forwarding aspect of this scenario, so @adityapatwardhan and company are going to be doing some investigation there as part of the prototyping effort.


[CLR Type Forwarding](https://docs.microsoft.com/en-us/dotnet/framework/app-domains/type-forwarding-in-the-common-language-runtime) will be considered to lessen the impact of the breaking change.

The interactive user experience would not change as command discovery will find the ```Get-Help```, ```Save-Help``` and ```Update-Help``` commands from the 'Microsoft.PowerShell.HelpSystem' module instead from 'Microsoft.PowerShell.Core' module (System.Management.Automation.dll).

This comment has been minimized.

@HemantMahawar

HemantMahawar Jul 25, 2018

Member

We need to make sure that scripting scenarios with fully qualified module names (Microsoft.PowerShell.Core\Get-Help) is NOT broken. PowerShell engine should support both - old module qualified names and the new module qualified names.

Plan to implement: Yes
---

# Help System as a standalone PowerShell Module

This comment has been minimized.

@HemantMahawar

HemantMahawar Jul 25, 2018

Member

We should put this new module behind experimental flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment