Script installation should require less fiddling with PATH

[Sean Williams]

Summary of the new feature / enhancement

As a PSResourceGet consumer (and overseer of many PowerShell-enabled systems, and provider of PSResourceGet-based deployment pipelines for other teams with varying levels of PowerShell experience), I want [my users, and my users' customers] to use scripts installed via PSResourceGet without the complex process of manually updating the PATH [on every user profile].

Consider the case of modules - $env:PSModulePath is pre-set at the OS/runtime level, and installing modules via PSResourceGet to either user- or machine-scope directories is lands in a directory listed in PSModulePath without any manual configuration. Installed modules are more-or-less guaranteed to be immediately available.

Scripts in machine scope are installed to a folder not in the PATH, which is a bit frustrating - however, it's easy enough to update the machine path for all users (current and future) at time of setting up PSResourceGet.

OTOH, scripts installed in user scope (the default selection with PSResourceGet) are installed to:

• A folder commonly redirected via Known Folder Redirection/Roaming Profiles, meaning:
  • It can't be one-and-done calculated for all users (can't guarantee every profile is KFRed in the same way, etc.)
  • Figuring out where the folder actually is requires either:
    • Loading the user's registry hive
    • Running code as the user (logon script, scheduled task, etc.)
• A folder not explicitly defined by PSResourceGet (#1625), so users have to recalculate the path themselves (a nontrivial task given KFR &co.)
• A folder not guaranteed to be a subpath of predefined environment variables (as is the case with %LocalAppData%, %AppData%, etc.), so there's no shorthand way to figure out its location (closest option is [Environment]::GetFolderPath("MyDocuments"))
• A folder commonly synced via cloud services like OneDrive (What happens if a script is synced between two devices? Would the InstalledScriptInfo be gracefully handled in a multi-device scenario?)

Emitting a warning when the install directory isn't in the PATH is helpful, but the process for editing user environment variables is so arduous on Windows that this process doesn't set people (especially new users) up for success. For teams distributing PowerShell scripts to technical customers without PowerShell expertise, the amount of per-user/-machine setup needed to execute scripts installed via PSResourceGet makes it significantly less attractive than modules.

Proposed technical implementation details (optional)

Some non-exhaustive options for fixing this could include:

• Exposing a new cmdlet in PSResourceGet (Register-PSScriptPathEntry?) for adding install directories to the user/machine's PATH variable (much like PowerShellGet used to do, but moved off the critical path for installation)
• Surface installation directories as a variable (a la PowerShellGet) so writing bolt-on automation to configure PATH vars is less complex
• Expose a helper function for invoking scripts (e.g. Invoke-InstalledPSScript) specifically if they were installed via PSResourceGet, regardless of PATH state
  • (this might cause confusion in tab-complete/DynamicParam behavior, but throwing it out for the sake of discussion)
• Work with the runtime team to adjust script search/load behavior s.t. a non-PATH envvar specific to PowerShell (PSScriptPath?) can be used to reference scripts specifically in a PowerShell session, then pre-load with script directories like PSModulePath is today