Add initial draft

[jshigetomi]

This pull request proposes a new RFC (RFC0066) to change the default location of PowerShell user content on Windows machines from OneDrive to the AppData directory. The goal is to align PowerShell with other developer tools and improve usability by preventing unnecessary syncing issues.

Key changes include:

• Introduction of RFC0066 to move PowerShell user content to the AppData directory on Windows.
• Specification of the new directory structure in AppData and the creation of a configuration file to manage the user scoped PSModulePath.
• Allowing users to customize the location of PowerShell user content, with certain directories being non-configurable.
• Providing an example script to relocate existing PowerShell content to the new location.

[sdwheeler]

There are many more comments and questions I want to add. But start with these changes.

[sdwheeler]

Suggested change

	- The PowerShell user content folder will be located in the AppData.
	- The PowerShell user content folder will be located in the `"$env:LOCALAPPDATA\PowerShell"`.

[sdwheeler]

Or should this be "$env:LOCALAPPDATA\Microsoft\PowerShell"? The already use this location module cache and SecretManagement.

[jshigetomi]

$env:LOCALAPPDATA\Microsoft\PowerShell makes more sense

[sdwheeler]

We should get @SteveL-MSFT feedback. I prefer to not create yet another PowerShell folder somewhere, but that folder get very full of files.

[sdwheeler]

Why aren't we allowing the location of the content folder to be changed? I want all my user files in one location, I don't want modules in one place and scripts/profiles in another.

[jshigetomi]

I see. So only the location of the config file itself is not configurable and all other files is configurable through the config file.

[sdwheeler]

I see. So only the location of the config file itself is not configurable

Correct. Whether the other locations are configurable is open to discussion. My vision was that we would only allow configuration of the PSContentPath. Everything else would be in that location.

PSContentPath (configurable)
├── Scripts (Not Configurable)
├── Modules (Not Configurable)
├── Help (Not Configurable)
├── profile.ps1 (Not Configurable)

[sdwheeler]

PSModulePath is already a value used in the config file. I suggest changing the name for this configuration to UserPSModulePath. If we allow rehoming of the content folder then use UserPSContentPath.

Use the suggested formatting.

Suggested change

	{
	"PSModulePath" : "C:\\Users\\chungjustin\\PowerShell"
	}
	```json
	{
	"PSModulePath" : "C:\\Users\\chungjustin\\PowerShell"
	}
	```

Question: Should setting PSModulePath and the user paths be mutually exclusive?

[jshigetomi]

I think making them not mutually exclusive is a good idea. And maybe even separating the scripts and profile out too?

{
"PSModulePath": "C:\Users\user\PowerShell",
"UserPSModulePath": "C:\Users\user\PowerShell",
"UserPSContentPath": "C:\Users\user\PowerShellContent"
"UserScriptPath": "C:\Users\user\PowerShellContent"
"UserProfilePath": "C:\Users\user\PowerShellContent"
}

[sdwheeler]

More comments

[sdwheeler]

I see. So only the location of the config file itself is not configurable

Correct. Whether the other locations are configurable is open to discussion. My vision was that we would only allow configuration of the PSContentPath. Everything else would be in that location.

PSContentPath (configurable)
├── Scripts (Not Configurable)
├── Modules (Not Configurable)
├── Help (Not Configurable)
├── profile.ps1 (Not Configurable)

[jshigetomi]

@sdwheeler Is this directory structure and configurability setup what you mean?

[iSazonov]

The file should have .md extension.