Remove hardcoded path to choco.exe and use %ChocolateyInstall% / $env:ChocolateyInstall env variable to find it.

[bcurran3]

It should not be assumed that Chocolatey choco.exe is found in c:\programdata\chocolatey as it can be installed elsewhere.

Upon install, Chocolatey sets a system environmental variable pointing to where it was installed, this is %ChocolateyInstall%/$env:ChocolateyInstall and that environmental variable is best practice to find the location of choco.exe. v0.98(?) and before used c:\chocolatey

Also, Chocolatey doesn't install apps, it installs packages which in turn are most likely programs.

[CLAassistant]

All committers have signed the CLA.

[silversword411]

When TRMM installs choco, it requires a reboot to initialize the environment variables. That's why the path was updated to the current values (will work for onboarding tasks prior to agent reboot).

Although %ChocolateyInstall% may be best-practices for Chocolatey, this will reintroduce the problem of failing choco installs till a restart has occurred. I can also see if you have separate Choco installs along with TRMM managed choco installs. TRMM only installs Choco to the path in this script and is not customizable. What is going to be the final results of that Environment variable?

Do you have any other ideas on how we can handle all these issues?

[bcurran3]

ChocolateyInstall env variable is available immediately after installation of Chocolatey, I can't confirm how far back version wise this is true, but in recent versions (probably back to before .9x though) it's true and I just confirmed it in a VM with 2.2.2.

At the end of a Chocolatey install it runs C:\ProgramData\chocolatey\redirects\RefreshEnv.cmd which refreshes the environment ('natch) making the ChocolateyInstall and ChocolateyLastPathUpdate variables available to the shell as well as adding C:\ProgramData\chocolatey\bin to the path (foreshadowing here).

DISCLAIMER: I have not installed Chocolatey via TRMM. I've got only a few hours experience with TRMM. I tried the "Chocolatey - List Installed apps" script and it worked perfectly. I found the "Chocolatey - Install, Uninstall, List and Upgrade Software" script to be unintuitive as I couldn't get it to do anything and there is no option to view the script or get help with parameters for the script inside TRMM that I could find during my minutes of testing.... that's what led me to find the source of the actual script.

You mentioned "TRMM only installs Choco to the path in this script and is not customizable" - I haven't seen the script that installs Chocolatey yet. I just did a quick look through the community scripts and didn't see it. I'll have to go digging further later.

I need to do further research looking at and running the rest of the related scripts, but to handle these issues (I should have quoted your response questions and replied inline!) would be to change

$chocoExePath = "$env:PROGRAMDATA\chocolatey\choco.exe"

if (-not (Test-Path $chocoExePath)) {
    Write-Output "Chocolatey is not installed."
    Exit 1
}

to first test $env:ChocolateyInstall exists and set $chocoExePath if so. Second I would look for choco.exe in the the way you are doing it which will most likely be the place 99.99% of the time. The next logical way would be to use Get-ChildItem to find choco.exe (there are three, the one in bin "should" be used) which would be intensive as it should check all available drives; i.e. a locked down computer user might have Chocolatey installed in their user folder or possibly on a network $env:HOMESHARE.

Expounding on the choco.exe "should" be used from bin folder.... When Chocolatey installs it adds c:\programdata\chocolatey\bin to the path wherein lines a choco.exe, a shim that runs c:\programdata\chocolatey\choco.exe. It's probably best to point to the shim in the bin. I don't know any reason that it needs to use the shim as running the choco.exe from c:\programdata\chocolatey works just fine, BUT I'm guessing there IS a reason the devs configured Chocolatey by default to run the shim... Running choco.exe proper instead of the shim may have consequences during a Chocolatey program upgrade - I'm completely guessing here; just trying to keep Chocolatey as (ack hum - clearing throat getting ready for the pun...) "vanilla" as possible.

[silversword411]

Can't beat a little white chocolate 😂

[silversword411]

Choco install is either part of agent repo....or it's a payload delivered by TRMM. I'm guessing it's part of agent install though.

Community Library is just scripts for TRMM (designed to run from SYSTEM)...not specifically about Choco.

[silversword411]

I'll try and retest virgin system with install to see if Choco in the env is still a problem or not. Been a year since I last did thorough testing.

The Choco install script used to warn about close/cmd/powershell windows after install to load env. Does it still do that?

[bcurran3]

Can't beat a little white chocolate 😂

Personally not a fan. :-) It's a misnomer. There is no chocolate in white chocolate! Nestlé attempting to FTW (fool the world).

Community Library is just scripts for TRMM (designed to run from SYSTEM)...not specifically about Choco.

100% understood. Repo is aptly and intuitively named.

The Choco install script used to warn about close/cmd/powershell windows after install to load env. Does it still do that?

Yepper depper.

WARNING: It's very likely you will need to close and reopen your shell before you can use choco. PATH environment variable does not have C:\ProgramData\chocolatey\bin in it. Adding...

Immediately post install (tested seconds ago):

dir env:

ChocolateyExitCode 0 ChocolateyInstall C:\ProgramData\chocolatey ChocolateyLastPathUpdate 133609673236589791 (results truncated)

EDIT: PLUG: Use my https://community.chocolatey.org/packages/choco-sandbox for super quick testing. :-)

[silversword411]

Yepper depper.

WARNING: It's very likely you will need to close and reopen your shell before you can use choco. PATH environment variable does not have C:\ProgramData\chocolatey\bin in it. Adding...

So then nothing's changed, which isn't surprising. As this is just how programs and their runtime env in the os work. Would love to use best-practices of having a proper choco env var...but because:

1. TRMM agent install installs choco and its env
2. trmm agent doesn't restart/reload it's runtime env...it won't have the envs yet without a trmm agent .exe/service reload
3. Someone might have onboarding scripts that trigger right away before agent/PC restart

I don't think updating scripts to use this path method. Am I missing anything?