PowerShell
Move PS content out of OneDrive
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.
Should we lock PowerShell/PowerShell/issues/15552 whilst this RFC is in progress or is it worth keeping open still?
@jshigetomi just a quick pause to thank you for all your hard work on this :)
In 75e359c (#388) , is there a particular reason you now appended Microsoft to the path? That doesn't exist today and will require migration on Linux, etc. which is why %LOCALAPPDATA%\PowerShell was the recommended path.
I think that the final destination path (PowerShell vs Microsoft/PowerShell) is still something that should be of discussion and debate, but I don't want that to derail the rest of the document cleanup so it can be tabled till we get closer to a final draft.
@kilasuit @fflaten @JustinGrote @HeyItsGilbert @daxian-dbw @sdwheeler @iSazonov Thank you all so much for sharing your insights on this issue. I've updated the RFC with the all the discussions up until this point to include out of scope considerations. I'm for the destination being under PowerShell and not Microsoft/PowerShell. Should we add an environmental variable for this path?
@jshigetomi it's my opinion the path should be fetchable by a public static method (Something like SMA::GetDefaultModulePath()) that, unless otherwise specified by configuration values, should default resolve to System.Environment.GetFolderPath('LocalApplicationData') path concatenated with powershell (all lowercase). This should be the API, we should not set an Environment variable in my opinion as the user can do that themselves if needed, though accepting an environment variable to specify the path from a parent process would be acceptable as an interface to configuration.
If the folder doesn't exist, it should be created as PowerShell on windows, powershell on all others, but then the same unified path resolution applies (and the case insensitivity of windows will still cause it to resolve correctly), letting .NET handle the OS path translations rather than trying to do it in PowerShell.
Programs and vendor specific implementations can override this as part of their config files to make it MyVendor\PowerShell or wherever, and users can still opt to set it back to My Documents if they prefer the roaming profile/onedrive sync/whatever.
Ship it!
I don't understand the reasoning to put these files in Documents, when they are NOT documents. It was always illogical and the LocalAppData is there for this specific scenario.
If one would not put ones Nuget packages in Source Control, why would one put ones installed Powershell modules in OoneDrive...
This just needs changed / fixed.
@MrHinsh Everyone agrees that this needs to be fixed, the question is how exactly, your comment does not help anything.
It seems to me that the discussions on here for 9 months on "how" to change a variable to another value is analysis paralysis.
This is something you just fix, not plan for 9 months.
The problem is not changing a single variable, the problem is changing the whole ecosystem to use a different path and doing it in a way where external programs no longer need to hardcode the path, so that, e.g., portable mode works. If it was trivial, it would be done already.
@MrHinsh ModuleFast already saves to LocalAppData by default and ModulePath can be used to change the default modules path (this will not affect PowerShellGet because it is hard coded there), so you have options here until this is resolved.
It seems to me that the discussions on here for 9 months on "how" to change a variable to another value is analysis paralysis.
This is something you just fix, not plan for 9 months.
@MrHinsh I agree in an ideal world, where it was just that simple, but it's not, however we are close to having this fixed and I'm doing my best to get this fix in right & much quicker than perhaps the team were wanting to do so. Mostly so that we can move on from this & get on with the more important things.