Let's move PSModulePath out of the documents folder

[JohnLudlow]

Summary of the new feature/enhancement

The documents folder has always been where modules user-scoped are kept, and that's always been ok, but I recently discovered some problems with this as I've been getting more familiar with Azure and my work laptop maps Documents to OneDrive. This can be problematic for a few reasons, such as OneDrive not syncing correctly or trying to restore a bunch of files from a module I just uninstalled. This is particularly an issue with larger modules (or groups of modules) such as Az.*

We can certainly wish OneDrive was better at its job, but really these files shouldn't be there - they are not documents. The user is not expected to edit them or look at them. They are more akin to application files or application data. There's no value to them being in OneDrive other than to transfer them to another machine, and that can be better achieved by having a script in OneDrive that calls PSDepend or PowerShellGet to install modules on that other machine.

I have updated my profile script to remove this path but it reappears after running install-module.

Proposed technical implementation details (optional)

1. Remove Documents\PowerShell\Modules from the $env:PSModulePath default. Select a new default path such as ~\PowerShell\Modules or $env:localappdata\PowerShell\Modules
2. Offer a cmdlet or documentation to move the existing modules to the new location, and optionally update the value of the environment variable.
3. Additionally, offer to move the existing modules and update the value of the environment variable during the install. (That way the user has the choice to make the install take care of it or do it later at a time of their choosing).

[jeroenlandheer]

A few extra things to consider when putting this up for triage:

• When I install a module on one machine and I am later at a different PC, OneDrive updates the modules folder... but Upgrade-Module doesn't work anymore, because it says the module wasn't installed with Install-Module ... (which it was, just not at the machine I'm working on.)
• If your module folder is big loading PowerShell can take a (very) long time because it will wait until OneDrive has pulled all the files to your machine.

I think this change should happen... hopefully soon. I think storage for these modules should be in the %userpfile%\AppData\Local folder, this is the place for things that should not get synced with other machines.

PS: I create PowerShell modules... I have a lot of them... and they are all on my OneDrive now. 😒

[iSazonov]

@jeroenlandheer Do you mean Update-Module? If so you couls discuss in PowerShellGet repository.

[JohnLudlow]

@iSazonov Would the PowerShellGet guys be able to change the default value of $env:PSModulePath and update the installer to optionally update it on upgrade?

Though there should probably be a second issue in PowerShellGet to respect the value, not overwrite it.

[iSazonov]

@JohnLudlow Any changes related to PSModulePath are breaking changes. We need to keep backward compatibility.

[jeroenlandheer]

@iSazonov Sorry, that was a typo. This should indeed go there too, but don't you think they will choose the location of the modules where they install them... based on whatever this teams says it should be? (AFAIK there's no way to customize this with settings, but that's something for another day.)

If paths for loading the modules is the primary function of PSModulePath, this issue can be solved quite easily:

1. Designate a folder somewhere in %LocalAppData%\...
2. Tell others that installing modules in this folder is best practice.
3. Put both paths in PSModulePath (i.e. %LocalAppData%\.. and %userprofile%\Documents\...)
4. Ensure the new location is added to new installations in the PSModulePath environment variable.

No need to move stuff around, new things get installed in %LocalAppData%\.. and old modules that are still in the user's documents folder keep working. Maybe this doesn't even require a code change in PowerShell, just some changes in the installer.

And now we're on this subject, in Windows installations, modules which are installed on the local machine are installed by default in the Program files\PowerShell\Modules folder. I think the correct place for this should be %AllUsersProfile%\... (often called C:\ProgramData)

AFAIK the functionality of PSModulePath itself doesn't change with all of this, so this is technically not a breaking change.

Hope this helps.

[JohnLudlow]

@jeroenlandheer Indeed, and if I do want to move the older modules to the new folder (I probably would, in my case), there are some options:

• Offer to do that in the installer
• Offer a tool (such as a cmdlet) to do it post-install
• Offer documentation that says "you can copy everything from <old location> to <new location>"

Any of those would work for me, but some people may appreciate it being done for them.

And you're absolutely correct IMHO about the Windows Modules. The only modules that should be there are ones that are installed as part of PowerShell and shouldn't be removed.

[SeeminglyScience]

AFAIK the functionality of PSModulePath itself doesn't change with all of this, so this is technically not a breaking change.

While I agree that it would be hard to claim this is explicitly a breaking change of an API, it would still be disruptive. There has never been a supported way of determining the module paths of different scopes, e.g. no PSModuleInfo.AllUsersModuleRepository or similar. Any tools looking to interact with the module directories explicitly has been required to hard code the path, so any location change here will break these tools.

(Note that I'm not necessarily advocating against it, but it's something that needs to be considered)

[rjmholt]

Related: #7082 (comment)

[kilasuit]

Previously discussed in #8069 too