chocolatey-archive/chocolatey

Invoking Update-SessionEnvironment from chocolateyInstall does nothing

Closed this issue · 6 comments

I have an install script which updates the $env:PSModulePath environment variable.

I do this then call Update-SessionEnvironment expecting to then be able to see $env:PSModulePath post install of the package via chocolatey.

$env:PSModulePath is not updated. Only if I restart powershell will $env:PSModulePath be what it's expected to be.

It is updated. See for yourself by adding the following to your chocolateyInstall.ps1:

Write-Host $env:PSModulePath
Update-SessionEnvironment
Write-Host $env:PSModulePath

Now, once chocolatey EXITS and you come back to your shell (which is likely powershell), $env:PSModulePath is whatever the shell was started with + any changes you have explicitly set.

If you want Update-SessionEnvironment to work, you need to import the chocolateyInstaller.psm1 module into your current shell session and call Update-SessionEnvironment.

HTH.

For clarity, this is not a chocolatey issue, this is is how child processes work on Windows. They have limited abilities to affect their parent process, which we can all agree is a good thing based on security issues that having that ability would create.

Also a duplicate of #666

I'm aware the value is updated inside of the session chocolateyInstall.ps1 is running in but that is worthless for my usage scenarios. I need the variable to be updated in the parent session.

Just to be clear I did as you say and a run through of the result is:

cinst posh-ci -source C:\TEMP
Chocolatey (v0.9.8.28) is installing 'posh-ci' and dependencies..

# output from chocolateyInstall.ps1
# invoke $env:PSModulePath
unchanged value
# invoke Update-SessionEnvironment
# invoke $env:PSModulePath again
changed value

Posh-CI has finished successfully! The chocolatey gods have answered your request!

#ok so chocolatey did the install.. now invoke $env:PSModulePath
unchanged value

I'm just curious but why is chocolateyInstall.ps1 run in it's own session and not the session used to invoke cinst with?

I understand the problem; it just seems an approach could be taken which did not result in this limitation; i.e. not using a child session to perform the actual install. Where is the requirement for an entirely separate session coming from? just seems unnecessary/ convoluted

I think part of the problem is that you believe that chocolatey is meant to be invoked from PowerShell because it is written in PowerShell and it's not meant to be a powershell module/script. It's a tool that can be executed from any shell. Let's be completely clear - this chocolatey is written in POSH. It is within days of being deprecated for choco (https://github.com/chocolatey/choco) which is written in C# and has a posh install provider.

It's entirely possible that we will include a module that you can add to your profile that will give you this behavior.