C:\tools vs C:\ProgramData\chocolatey\tools\ vs C:\ProgramData\chocolatey\lib\ directories

[mesvam]

I don't quite understand chocolatey package installation/storage and I'm hoping somebody can educate me.

I was cleaning up the C:\ root directory and noticed that some chocolatey packages (e.g. NirLauncher, choco-cleaner) install into C:\tools instead of C:\ProgramData\chocolatey\lib\

Why do they do this? There is already a tools directory at C:\ProgramData\chocolatey\tools\ so why is the ChocolateyToolsLocation environment variable set to C:\tools instead of C:\ProgramData\chocolatey\tools\? If I change ChocolateyToolsLocation to C:\ProgramData\chocolatey\tools\ will that cause any problems? Why don't packages like these install into C:\ProgramData\chocolatey\tools\ or even better C:\ProgramData\chocolatey\lib\ instead like everyone else? Why aren't 7z, checksum, and shimgen in C:\ProgramData\chocolatey\tools\ installed in C:\ProgramData\chocolatey\lib\ as packages?

Basically what is the difference between C:\tools, C:\ProgramData\chocolatey\tools\, and C:\ProgramData\chocolatey\lib\? I can't find documentation on this, so I don't understand the reasoning behind keeping these directories separate.

[TheCakeIsNaOH]

For my answer I'm assuming Chocolatey CLI is installed to C:\ProgramData\chocolatey.

C:\ProgramData\chocolatey\tools\ is a directory that Chocolatey CLI uses to store tools that it includes by default, and uses while installing packages. These tools are 7z.exe, checksum.exe, and shimgen.exe currently. These are not intended to be used directly, and are a part of the internals of Chocolatey CLI. They cannot easily be setup as packages because they are used while installing packages, so it's a chicken and egg problem if they were to be installed into C:\ProgramData\chocolatey\lib\, and they are intended to be kept in lockstep with the version of Chocolatey CLI that is installed to ensure that everything works correctly.

C:\ProgramData\chocolatey\lib\ is the location that packages are installed too. Chocolatey CLI manages packages, and packages install/upgrade/uninstall software. So in C:\ProgramData\chocolatey\lib\<packageID> is where the package files go, so the .nupkg, .nuspec, chocolateyInstall.ps1, VERIFICATION.txt etc. For some packages, the software that the package installs is installed into C:\ProgramData\chocolatey\lib\<packageID> folder (or a subfolder). Other times, a package may install software to other locations on the system.

C:\tools is the default location of $env:ChocolateyToolsLocation. It is the location for packages to put portable software (i.e. software that does not have an installer or other defined installation location) which would not work well in C:\ProgramData\chocolatey\lib\<packageID>. For example, gsudo does not work with shims, and in order to put it on the system path, and to enable upgrades while the old version is still in use the gsudo package installs gsudo.exe to a folder under $env:ChocolateyToolsLocation. Other cases I know of involve requiring the software to be on the path (and shims were not suitable), or for the directory permissions to be changed.
Note that if you are accessing it in a package automation script, use Get-ToolsLocation instead of accessing the environment variable directly.

If I change ChocolateyToolsLocation to C:\ProgramData\chocolatey\tools\ will that cause any problems?

I don't know of any reason it wouldn't work for the current version of Chocolatey CLI. But I definitely would not recommend it because there could well be something that I am missing, and/or it may cause problems with a future version of Chocolatey CLI.

[mesvam]

Very nice comprehensive answer! Thank you very much.

A bit of follow up if you don't mind.

C:\tools is the default location of $env:ChocolateyToolsLocation. It is the location for packages to put portable software (i.e. software that does not have an installer or other defined installation location) which would not work well in C:\ProgramData\chocolatey\lib\<packageID>. For example, gsudo does not work with shims, and in order to put it on the system path, and to enable upgrades while the old version is still in use the gsudo package installs gsudo.exe to a folder under $env:ChocolateyToolsLocation. Other cases I know of involve requiring the software to be on the path (and shims were not suitable), or for the directory permissions to be changed.

If you were creating a package with these quirks, is there any reason why you would not want to put these files (not shims) directly into C:\ProgramData\chocolatey\bin instead of $env:ChocolateyToolsLocation? It seems like Get-ToolsLocation used to be Get-BinRoot and C:\tools used to be C:\chocolatey\bin chocolatey-archive/chocolatey#660, so when C:\chocolatey\bin was transitioned to C:\ProgramData\chocolatey\bin, how come C:\tools didn't go into the same location?

[TheCakeIsNaOH]

so when C:\chocolatey\bin was transitioned to C:\ProgramData\chocolatey\bin, how come C:\tools didn't go into the same location?

I haven't been around that long, so I don't know all the context to explain the history.

If you were creating a package with these quirks, is there any reason why you would not want to put these files (not shims) directly into C:\ProgramData\chocolatey\bin instead of $env:ChocolateyToolsLocation?

At least two reasons:

1. Oftentimes when a .exe does not work well with a shim, it is not just a single .exe, (like gsudo), but a full folder structure with things like .dlls, data files, and config files that they .exe expects to in the same folder as it. Copying this extra stuff would clog up the bin folder, and there would be a very high likelihood of file conflicts.
2. It does not take care of the case of having to change file permissions. Some programs may have a config file that is required to be right next to the .exe, and that config file needs to be writable by normal users, not just admins. By default, C:\ProgramData\chocolatey is intended to be locked down, so only admins can write to it. Using Get-ToolsLocation (aka C:\tools) gets around this.