Powershell shouldn't install modules to MyDocuments as thats not for applications

[simonsabin]

Microsoft is pushing more and more during Onedrive setup to have MyDocuments managed by onedrive.

Being a good dev and not running elevated means installing packages with -Scope CurrentUser but this means packages are stored in MyDocuments\WindowsPowershell or MyDocuments\Powershell. This means all modules are then synchronised up to OneDrive.

This is made worse by sporadic issues due to connecting of Onedrive.

1. Collisions with OneDrive and the install-module resulting in modules not saving correctly
2. Modules not used in a while get "archived off" and thus are downloaded on demand by onedrive resulting in problems when trying to load modules

Use of AppData would be much more appropriate for modules.

related items #41

[issue-label-bot]

Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.85. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[Jaykul]

I totally agree with the sentiment. My Documents*PowerShell\Modules is a growing percentage of my OneDrive.

My problem is that I'm not sure that changing it is worth the confusion it would cause for users.

1. Since the begining, the $Profile location has been in documents, and I think it clearly belongs there.
2. Since Modules were added, the .\Modules subfolder of that location has been the only per-user module folder that is on the search path by default.
   3, The "all users" location has moved around, so this is the only totally backward-compatible install location.
3. Since PowerShellGet was created, there's only been "All Users" vs. "Current User" as the install location option, with hard-coded paths, so changing our PSModulePath has been ... impractical.

I can think of a few options I don't like:

1. A breaking change to where PowerShell expects the $Profile to be
2. A breaking change to where PowerShell expects the default user module path to be, but leave $Profile where it s
3. Making the default module path flexible. For instance:
   1. Add a new configuration variable (or environment variable) ignoring PSModulePath
   2. Use the first PSModulePath value that's somewhere below $Home folder
      E.g. Push-Location $Home; $ENV:PSModulePath.Split(';').Where{(Resolve-Path -Relative $_) -notmatch "$.."}[0]; Pop-Location
   3. A combination, requiring a PSModuleInstallPath to point to something that's also in PSModulePath

I really don't like any of these options, but more importantly, I think they would be such a big change that we would basically obsolete all documents and blog posts and stack overflow answers about how all of this works...

(Edit) One option that might make sense to me:

Keep the current profile and module search locations, but add a new PowerShell folder in AppData -- or possibly adopt a linux option like: $Home/.PowerShell

I imagine it would have the full functionality of the current "PowerShell" folder:

1. It would get added to $profile (replacing $Profile.CurrentUserAllHosts and relegating the old value to $Profile.CurrentDocumentsAllHosts?
2. A "Modules" subfolder would get added to PSModulePaths
3. A "Scripts" subfolder would get added to the PaTh ...

Then PowerShellGet v3 would install to that new location by default, perhaps adding a third option to the -Scope like "Documents" for the legacy location, and treating "CurrentUser" as the new location ...

[simonsabin]

Not sure whats more confusing a 3rd option, or change the other option. We already have Core behaving differently Windows with the default. This all stems from the fact that the docs all say is $Home\Documents but actually its inconsistent in some locations its "my documents" special folder and some its $home\documents. with the 2 not resolving to the same location on a machine with a redirected $My documents location.

[russellds]

A solution would be to use a config file similar to about_PowerShell_Config PSModulePath. This requires zero changes to existing documentation while enabling the ability to change the paths.

[simonsabin]

As per the warning on that page install-module ignores that. This doesn’t solve the problem

[RobertKlohr]

I want to add another point as to why we need the ability to change the installation path.

1. The user scope installation path is hard coded in install-module. <= This is NEVER an acceptable practice.
2. The folders protected by Controlled Folder Access are also hard coded. <= This is NEVER an acceptable practice.
3. If you use PowerShell and have Controlled Folder Access you lose the ability to install or update PowerShell modules in the currentuser scope because two development teams have chosen to hard-code conflicting configurations.

The only way to fix this issue is to enable PowerShell for Controlled Folder Access bypass but doing that is not best practice and is explicitly against Microsoft's configuration recommend, and for good reason.

As Standard User

As Administrator

Blocked