Download chocolatey packages for offline installation

Question

I'd like to download a bunch of chocolatey packages and later install them on another PC (which has a bad internet connection, so I cannot just install them in a usual way).

Yes, I could just download installers one-by-one and then install them consecutively. But there are quite a lot packages (around 20) and I really, really like the UNIX way of doing things.

So, is there a way to do such a trick with chocolatey?

UPD: Probably there's a way to achieve this by using a custom Packages.config, where I explicitely change source. However, it expects a URL and not a local path. Running a server for a single use is an overkill for this task.

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="chocolateytestpackage" version="0.1" source="somelocation" />
</packages>

My experience with Homebrew gives me a clue that if Chocolatey stores the downloaded packages, I could just manually take them from the storage path on one PC and put to that path on the other one. Will research it further.

Answer 1

First let's address a misconception.

Source does not require a URL

Sources can be one of the following formats:

• HTTP/HTTPS OData Feed
• Local Directory
• CIFS Share / UNC share

See https://github.com/chocolatey/choco/wiki/How-To-Host-Feed#local-folder--unc-share-cifs for more information.

Offline cache

We've updated this question based on content at https://stackoverflow.com/a/18596173/18475

We call this process internalization. You can do this manually or look at Chocolatey for Business to do this.

Typically package maintainers on the community package repository do not have distribution rights for the actual software binaries, so the package needs instructions to go download those resources and act on them. This is not a limitation when using Chocolatey internally.

Caching Downloads - Not Deterministic

While there are ways to set the original nupkg (with the version on it, not the one in the packages directory - use download from left side of packages page on the Chocolatey community package repository) and preset the downloaded binaries into the cache folder, it's not always deterministic that it will work. You can also override the cache location, so that the folder is somewhere not in TEMP. See choco config, choco config -h and choco config set cacheLocation c:\some\location to do this.

NOTE: The cache will only support the same architecture, as in you can't take the results from an x64 machine and expect the cache to have 32-bit installers also downloaded.

Create Your Own Packages - Better

For packages you need offline, you have the ability to manage your own packages and you can embed software right into the package. This is desired when you want to manage software offline as most things on the community repository are subject to copyright law and distribution rights (why they don't simply have the software they represent embedded).

Creating and working with your own packages is very secure, but it does tend to take up time. If you are doing this for yourself, then it could override any time-savings you get as a consumer using Chocolatey and the community repository.

For organizations, we've developed Package Builder, which creates full software deployments (packages) in 5-10 seconds. It can also create packages right out of existing installed software (Programs and Features) in under 60 seconds! Read more about Package Builder.

Internalized Packages - Best

The best thing you can do here is a process called internalizing, where you download and extract the package, download all of the resources and embed them in the package (or put them somewhere local), edit the scripts to use those embedded/local resources and recompile the package.

This allows you to take advantage of existing package logic without the issue of the internet.

For more details see Manually Internalizing Packages and Package Internalizer - Automatically Internalize Packages.

Organization Use of Chocolatey

Most organizations using Chocolatey are doing some combination of creating packages and internalizing packages, because they need absolute trust and control over those packages when being used in production scenarios.