Update-SessionEnvironment doesn't update $env:PSMODULEPATH

[eavonius]

I have a PowerShell Module (PowerDelivery) that I've created an MSI with the Wix Toolset for. When I install this with Install-ChocolateyInstallPackage (it's embeded as a .msi in the nuget package installed by chocolatey) I see that the environment variable gets appended to (PSMODULEPATH, system variable) but after calling Update-SessionEnvironment in chocolateyInstall.ps1 the current PowerShell environment doesn't have this set.

My chocolateyInstall.ps1:

$installDir = $(Split-Path -parent $MyInvocation.MyCommand.Definition)
$msiFile = Join-Path $installDir PowerDelivery.msi

Install-ChocolateyInstallPackage 'powerdelivery3' 'msi' '/quiet' $msiFile

Update-SessionEnvironment

This fails, executing $env:PSMODULEPATH shows the old path
even though checking this in the Windows System Environment
Variables control panel applet shows the path to the module has
been appended:

Import-Module PowerDelivery -Force

[ferventcoder]

Can I ask if this is INSIDE the package or once you come back out to your shell?

[eavonius]

All these lines of example PowerShell are in my chocolateyInstall.ps1. When I call $env:PSMODULEPATH after chocolatey runs, this is after the chocolatey install fails.

If I omit the line to Import-Module there are no errors, but the module isn't loaded etc.

I used to set the environment variable myself with a bunch of manual string parsing that I can add back in but I thought Update-SessionEnvironment might do this for me?

[ferventcoder]

Ah okay, right on. Can you verify whether this is new choco only or also present with the older version?

[eavonius]

I'm using 0.9.8.32 (I see that 0.9.8.33 is available). Would you like me to upgrade to 0.9.8.33 and test again? I haven't tried the new chocolatey yet - can these run side by side? Thanks for looking at this Rob.

[ferventcoder]

Okay great, so this is an existing issue. 👍

[ferventcoder]

I mean not great that its a bug for you. But good that it is not something new choco introduced.

[eavonius]

Thanks for the clarification. I'm getting ready to release a new version of PowerDelivery that's a complete rewrite myself - so I figured I might as well use the latest chocolatey.

Are you going to have a "new" gallery for chocolatey or a way to say in a package "you have to use the new chocolatey to install me"? I actually use the choco list commands in a PowerShell script I wrote that automates releasing new versions to chocolatey but the two choco versions are a little different ;).

[ferventcoder]

or a way to say in a package "you have to use the new chocolatey to install me"?

Include chocolatey as a dependency in your nuspec, specify minimum version.

[ferventcoder]

We may have a bit of a need to update the environment between installs that happen in a row.

[eavonius]

Thanks Rob, I didn't know about the nuspec being able to control the chocolatey version dependency. That's awesome. Yeah basically the WiX file handles upgrading (removes the old package which removes the old PSMODULEPATH setting, the new version installs the new package and updates PSMODULEPATH again).

It would be cool if in chocolateyInstall it just says install the msi, update the session, and then import the module (with -force). In the chocolateyUninstall it says remove the module, uninstall the msi, and update the session (to remove the module from PSMODULEPATH).

[ferventcoder]

Is it possible the PSMODULEPATH has not yet been updated? You could add a registry check to spit out the values.

[jberezanski]

I believe this issue cannot be resolved assuming Chocolatey is used as a standalone executable. Whatever choco.exe would do to its environment, the changes would never propagate to the calling process (in this case, powershell.exe).

The only scenario in which the calling PowerShell environment could be updated would require a native PowerShell Chocolatey module (native in the sense that it would not call an external process, so #8 would be a requirement as well), so that everything would be done in-process.

By the way, this was achievable in PS Choco if one bypassed chocolatey.cmd and invoked chocolatey.ps1 directly (not officially supported, but it worked).

[ferventcoder]

You know that little refreshenv we have that works with cmd.exe? I'd planned to create something similar that worked with powershell.

[jberezanski]

Sure, a separate powershell script would work, as a workaround - just not seamless.
But do keep chocolatey-archive/chocolatey#475 in mind (esp. regarding PSModulePath)...

[eavonius]

I try to use chocolatey in automated deployments as part of a larger process and this makes it finnicky. I really hate how updating an environment variable through powershell has to both update the registry AND the current environment, and how that doesn't propogate to the calling process. If you make a permanent change to the path, how could you not want the next installed package or calling process to have that look permanent like it is? Just something to ponder I guess.

[eavonius]

If I put this in chocolateyinstall.ps1 after my MSI is installed (that changes the PSModulePath):

$ENV:PSMODULEPATH = (Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Session Manager\Environment' -Name PSMODULEPATH).PSMODULEPATH

Is this going to propogate to the process calling chocolatey or do I need to do it there as well?

[ferventcoder]

Possible way around this:

• https://gist.github.com/Iristyle/9a870f96f1896710c01f#file-env-reset-ps1-L4

[ferventcoder]

This conflicts with #295 in a way.

[eavonius]

Looking at Update-SessionEnvironment, you've already got code to handle combining PATH using the Machine and User settings - curious why this doesn't also work for PSMODULEPATH? Would treating the hierarchy of overrides as Machine, then User, then Process fix this?

[pauby]

This looks like it was resolved under #439?

[github-actions]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue will be closed in 14 days if it continues to be inactive.

[github-actions]

Dear contributor,

As this issue seems to have been inactive for quite some time now, it has been automatically closed.
If you feel this is a valid issue, please feel free to re-open the issue if / when a pull request
has been added.
Thank you for your contribution.