Powershell: Expose easier way to get common locations: Cache, Config, Profile

[TylerLeonhardt]

Summary of the new feature/enhancement

This is similar to https://github.com/PowerShell/PowerShell/issues/11223 but a bit broader...

The cache and config are internal:

https://github.com/PowerShell/PowerShell/blob/b1e998046e12ebe5da9dee479f20d479aa2256d7/src/System.Management.Automation/CoreCLR/CorePsPlatform.cs#L143-L150

If a Host needs to implement $PROFILE support, they have to implement all of it from scratch.

We can expose Cache, Config and even a way to get the Profile. Every host shouldn't need to implement this on their own.

Proposed technical implementation details (optional)

Make cache and config public... and consider making something like this public too:
https://github.com/PowerShell/PowerShell/blob/b1e998046e12ebe5da9dee479f20d479aa2256d7/src/System.Management.Automation/engine/hostifaces/HostUtilities.cs#L225-L252

And other utilities in that class that other hosts would love.

[rjmholt]

Given that the body text here doesn't really capture https://github.com/PowerShell/PowerShell/issues/11223, I should add that these concepts are essentially something proposed to be added to the PSHost API as something that should have a sane default and be overridable, providing a way both for the host to communicate its configuration of certain common locations, but also for modules to query those locations.

Examples are:

• CurrentUser/AllUser module directories
• CurrentUser/AllUser profile paths
• Cache directory
• Config directory

My feeling is that these make sense as host APIs because hosts operate at the level of being built for a particular environment.

My proposed API is essentially something like:

public class PSHost
{
...

    // I know a boolean parameter is used above, but I'm conscious that boolean parameters are warned against in design literature
    public virtual string GetCurrentUserProfilePath() => DefaultGetCurrentUserProfilePath();

    ...
}

[bpayette]

@rjmholt Cache and config are engine features, so not host specific nor are the SpecialFolders host-specific.

@TylerLeonhardt It would be nice to fix this for both C# and PowerShell users. @JamesWTruher and I thought using ~ notation would work of scripters. For example, ~cache/zork would expand to <pathToCache>/zork. This would also be available to C# users through the existing Path APIs.

[rjmholt]

Cache and config are engine features, so not host specific nor are the SpecialFolders host-specific.

In that case, it sounds like we need a well known static surface within the engine.

[vexx32]

Yeah. Exposing it via paths is a nice-to-have for scripters, but there should also be a concrete surface within the engine it gets exposed directly in. Perhaps something in ExecutionContext or InvocationInfo?