Installing, Upgrading, and Uninstalling Your Package

Installation Paths

As the package maintainer, you decide where the packaged application is installed or extracted to. Depending on your type of application (see "What distinction does Chocolatey make between an installable and a portable application?" at the bottom of the FAQ) there are a couple of suitable locations (not listed in any particular order):

1. The Default Installation Path of Your .msi/.exe Setup File

The original creator probably had a reason for choosing a specific default installation path.
If you think, the user should be able to customize this path and you, the package maintainer, know how to pass a custom path on to the installer, then you should use %ChocolateyBinRoot%.

2. The package directory in %ChocolateyInstall%\lib\mypackage

You can extract the application within the package directory itself (or even ship an extracted version with the package). This allows Chocolatey to automatically find executables and put those on %path%.

3. Path provided by the Get-BinRoot helper - will be deprecated later (closer to v1) but okay to use for now

The path returned by the helper Get-BinRoot can be used as the parent directory for the installation. Get-BinRoot will return the value of the environment variable %ChocolateyBinRoot%. If the value does not contain a drive reference, the system drive will be prepended. If the environment variable is not set, the default path (C:\Tools C:\Chocolatey\bin) will be returned.

As an example, MinGW uses %ChocolateyBinRoot%. If the environment variable is not set, it will be set to c:\tools and MinGW will install to C:\Tools\MinGW by default. If %ChocolateyBinRoot% is set to "C:\Common\bin", MinGW installs to C:\Common\bin\MinGW.

%ChocolateyBinRoot% gives the Chocolatey user a way of controlling where packages are installed. If you want to allow customizing the installation path, then this is currently the way to go.

Make it clear in the package description

No matter how you decide, you are advised to state the default installation directory in your package description. This prevents confusion about where the application will end up being installed.

If you allow customizing the installation path, then append instructions on how to do that, too.

Install Only on Some Versions of Windows

Right now if the software the package installs is only supported on particular versions of Windows, you should absolutely fail the package. An installed package indicates success. If you pass a warning message but don't also throw an error, that means the package installed successfully. Folks using the package are going to be confused because they will then expect that the underlying software is also installed. The software itself may throw a cryptic error, which will lead to questions from the community about why it is broken (when it is just unsupported). Do yourself a favor and check the version of Windows and throw an error if it is not a supported version. Under no circumstances should you bypass with a warning, because a warning is still a success.

There is at least one noted exception to this and that is low-level packages that are meant as dependencies that need to be present even if they do not install anything. These are things like KBs that only need to be installed on some versions of Windows. If the package failed and it was a dependency of a higher level package that installed software, it would cause issues attempting to install that software on different versions of Windows. Since about 5% of the packages apply to this exception, stick with the above thoughts for packages.

Upgrading

Prior to choco version 0.9.10, there is no dedicated automation script for upgrade scenarios. Instead, your chocolateyInstall.ps1 script should support installing/upgrading on top of any previous versions of your package.

More recent versions of choco (0.9.10+) give you the option of supplying a chocolateyBeforeModify.ps1 script.
If applicable, the version of this script from the currently installed package will be run before subsequent chocolateyInstall or chocolateyUninstall scripts.

Uninstalling

Uninstalling is handled by a chocolateyUninstall.ps1 script, which should be in your package's tools directory, next to chocolateyInstall.ps1. All the usual helper reference are available. If your package doesn't uninstall cleanly, people will get grumpy because they'll have to manually clean up after you. Be a good human being and write an uninstaller.