Installing chocolatey removes $env:PSModulePath changes for current powershell session

[chrissimon-au]

When installing in a powershell process with something like:

iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

After the install, $env:PSModulePath has reverted to the Machine level environment variable.

This is causing problems for me as the Machine level variable only has:

 C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files (x86)\AWS Tools\PowerShell\

But as part of establishing a powershell session, $env:PSModulePath looks like:

C:\Users\Administrator\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files (x86)\AWS Tools\PowerShell\

After installing chocolatey, it reverts to:

 C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;C:\Program Files (x86)\AWS Tools\PowerShell\

And the absence of the Documents and Program Files paths causes problems for other things I'm trying to do in the same script.

Seems likely this is being done by Update-SessionEnvironment. The need for Update-SessionEnvironment is clear, but could it possible merge with the existing $env:PSModulePath rather than assuming that the process has not yet modified it?

[ferventcoder]

To be clear this is only during the install.

Where are the other values resolved from?

[chrissimon-au]

Yes, I've only noticed this during install.

Not sure where those other values are coming from. https://msdn.microsoft.com/en-us/library/dd878326%28v=vs.85%29.aspx suggests the Documents path is a default ($home\Documents\WindowsPowerShell\Modules) - perhaps it's being added by Powershell itself - but doesn't explain the Program Files path. I'm still hunting that down - will let you know if/when I find it.

But either way - shouldn't in-process changes to $env:PSModulePath be respected, wherever they've come from? If they were set by the script that's installing chocolatey, then you wouldn't be able to resolve them from anywhere other than $env:PSModulePath.

[ferventcoder]

The problem is that Update-Session is somewhat naive, it only loads the values from the registry.

[ferventcoder]

By the way, this is a duplicate of #129 - let's continue discussion there.

This is not a duplicate, it's only related.

[ferventcoder]

To be clear it's only messing up changes in the current powershell session. Once you close and reopen powershell, everything is back to normal.

[eavonius]

Hey guys just throwing a comment in here since I've been following this related to #129. Wouldn't it make sense that if any packages you install make persistent changes to the system or user PSMODULEPATH, at the conclusion of those packages, running refreshenv should cause PSMODULEPATH to be whatever is in the user variable (from the registry) and if a user level variable is not defined, it would be whatever is the system variable in the registry? This is what the command prompt normally does from testing I've done.

Curious what others think. Have run some of this by rob but I don't want to suggest he make a change that conflicts with what the rest of the community would expect. Thanks!

[ferventcoder]

@eavonius Stay tuned, I just put some c# code into Chocolatey that may correct #129 for you. See #439 and the commits associated with that.