【chocolatey】introduce

https://chocolatey.org/docs/getting-started 官网

The sane way to manage software on Windows

• Chocolatey builds on technologies you know - unattended installation and PowerShell. Chocolatey works with all existing software installation technologies like MSI, NSIS, InnoSetup, etc, but also works with runtime binaries and zip archives. Go Pro/Businessto dial that experience up to 11!
• Easily manage all aspects of Windows software (installation, configuration, upgrade, and uninstallation). Chocolatey is the most reliable when software is included in the package, but can also easily download resources.
• Take advantage of PowerShell to provide automated software management instructions and Chocolatey’s built-in module to turn complex tasks into one line function calls!

Chocolatey is a package manager for Windows (like apt-get or yum but for Windows). It was designed to be a decentralized framework for quickly installing applications and tools that you need. It is built on the NuGet infrastructure currently using PowerShell as its focus for delivering packages from the distros to your door, err computer.

Chocolatey is a single, unified interface designed to easily work with all aspects of managing Windows software (installers, zip archives, runtime binaries, internal and 3rd party software) using a packaging framework that understands both versioning and dependency requirements. Chocolatey packages encapsulate everything required to manage a particular piece of software into one deployment artifact by wrapping installers, executables, zips, and scripts into a compiled package file. Chocolatey packages can be used independently, but also integrate with configuration managers like SCCM, Puppet, and Chef. Chocolatey is trusted by businesses all over the world to manage their software deployments on Windows. You’ve never had so much fun managing software!

Chocolatey is brought to you by the work and inspiration of the community, the work and thankless nights of the Chocolatey Team, and Rob heading up the direction.

You can host your own sources and add them to Chocolatey, you can extend Chocolatey's capabilities, and folks, it's only going to get better.

Organizations that need better integration with Windows, more features and a smoother experience, not to mention a supported solution, turn to Chocolatey for Business.

With all of this in mind, think of Chocolatey as a framework that you can build on top of. Chef, Puppet, Boxstarter, PowerShell DSC, Ansible, Saltstack, etc all have ways for using Chocolatey to ensure the state of a computer and packages installed. Even Microsoft has decided to use Chocolatey's framework with the PowerShell PackageManagement / OneGet package manager aggregator! See Jeffrey Snover's post for more information.

https://chocolatey.org/install#installing-chocolatey  安装介绍 

Upgrading Chocolatey

Once installed, Chocolatey can be upgraded in exactly the same way as any other package that has been installed using Chocolatey. Simply use the command to upgrade to the latest stable release of Chocolatey:

choco upgrade chocolatey

 

How does Chocolatey work?

How the heck does this all work?

Installation

1. Chocolatey uses NuGet (NuGet.Core.dll) to retrieve the package from the source. This is typically a nupkg that is stored in a folder, share, or an OData location (HTTP/HTTPS). For more information on sources, please see Sources and Source Repositories.
2. The package is installed into $env:ChocolateyInstall\lib\<pkgId>. The package install location is not configurable - the package must install here for tracking, upgrade, and uninstall purposes. The software that may be installed later during this process is configurable. See Terminology to understand the difference between "package" and "software" as the terms relate to Chocolatey.
3. Choco determines if it is self-contained or has automation scripts - PowerShell scripts (*.ps1 files) and possibly other formats at a later date.
4. Choco takes a registry snapshot for later comparison.
5. If there are automation scripts, choco will run those. They can contain whatever you need to do, if they are PowerShell you have the full power of Posh (PowerShell), but you should try to ensure they are compatible with Posh v2+ (PowerShell v2 and beyond).
6. Choco compares the snapshot and determines uninstaller information and saves that to a .registry file.
7. Choco snapshots the folder based on all files that are currently in the package directory.
8. Choco looks for executable files in the package folder and generates shims into the $env:ChocolateyInstall\bin folder so those items are available on the path. Those could have been embedded into the package or brought down from somewhere (internet, ftp, file folder share, etc) and placed there. If there is a shim ignore file <exeName>.exe.ignore, then Chocolatey will not generate a shim in the bin folder.

Upgrade

1. Starting in 0.9.10, Chocolatey will look for and run a chocolateyBeforeModify.ps1 file in the existing package prior to upgrading or uninstalling a package. This is your opportunity to shut down services and/or processes. This is run from the existing package, not the new version of the package. If it fails, it just passes a warning and continues on.
2. Similar to install, except choco will make a backup of the package folder (and only the package folder) prior to attempting upgrade.
3. The files snapshot is used to determine what files can be removed from the package folder. If those files have not changed, they will be removed.
4. If the upgrade fails, choco will ask if you want to rollback the package folder to the previous version. If you choose to move roll back, it will put the backed up package directory back in place. This does not fix any folders you may have been using outside of the package directory, such as where the native installer may have installed a program to nor the location of Get-ToolsLocation/Get-BinRoot (e.g. c:\tools). You will need to handle those fixes on your own. Chocolatey also doesn't rerun any install scripts on rollback.

Uninstall

1. Choco makes the determination that the package is actually installed.
2. Starting in 0.9.10, Chocolatey will look for and run a chocolateyBeforeModify.ps1 file in the existing package prior to upgrading or uninstalling a package. This is your opportunity to shut down services and/or processes. If it fails, it just passes a warning and continues on.
3. Choco will make a backup of the package folder.
4. The automation script is run if found. This should be used to clean up anything that is put there with the install script.
5. If auto uninstaller is turned on, choco will attempt to run the auto uninstaller if a silent uninstall can be determined. Otherwise it will prompt the user (unless -y) to ask if they want the uninstaller to continue. The auto uninstaller can automatically detect about 80% of the different native uninstallers and determine or use the silent uninstall arguments.
6. If everything is successful so far, the files snapshot is used to determine what files can be removed from the package folder. If those files have not changed, they will be removed.
7. If everything is deleted from the package folder, the folder is also removed.

When a package has an exe file, Chocolatey will create a link "shortcut" to the file (called a shim) so that you can run that tool anywhere on the machine. See shimming for more information.
When a package has a chocolateyInstall.ps1, it will run the script. The instructions in the file can be anything. This is limited only by the .NET framework and PowerShell.
Most of the Chocolatey packages that take advantage of the PowerShell download an application installer and execute it silently.

Where are Chocolatey packages installed to?

Chocolatey packages are installed to ChocolateyInstall\lib, but the software could go to various locations, depending on how the package maintainer created the package.

Some packages are installed under ChocolateyInstall\lib, others - especially packages that are based on Windows installers (.msi files) - install to the default path of the original installer (which is most likely within Program Files).

There are also packages for which you can set a custom installation path. These packages (like ruby) use the $env:ChocolateyBinRoot environment variable. If this variable does not exist, it will be created as c:\tools e.g. C:\tools\ruby193. To change this behaviour, you can set $env:ChocolateyBinRoot to an existing folder, e. g. C:\somestuff. Packages that use the environment variable, will then be installed in the given subfolder, f. ex. C:\somestuff\ruby193.

How does Chocolatey work with Programs and Features? Existing installs?

Many packages use native software installers, so Chocolatey allows the installer itself to handle install/upgrade/uninstall scenarios. This means it can work directly with already installed software just by using choco install to make Chocolatey aware of existing software. You can also use a specially crafted install command (skip powershell) to allow choco to install a package without installing the already installed native software.

Where does Chocolatey install packages from?

By default it installs packages from chocolatey.org (the community feed). But you can change this by adding default sources and/or using the --source switch when running a command.

When you host internal packages, those packages can embed software and/or point to internal shares. You are not subject to software distribution rights like the packages on the community feed, so you can create packages that are more reliable and secure. See What are Chocolatey Packages for more details.