Glide install and the glide.lock file

With the 0.8 release of Glide comes the introduction of the glide.lock file and a new install command. When we introduced semantic version support in the previous release it left a feature gap between specifying version ranges and having reproducible builds down to the commit. This is the solution that, to be fair, has been implemented in numerous other programming languages package managers.

glide.lock file

When glide update is run it now updates the entire dependency tree and generates a glide.lock file with each dependency in the entire tree and the commit id for each dependency. This file is managed by Glide and shouldn’t be manually edited like the glide.yaml file.

This file is tied to a version of the glide.yaml file. So, if you change the glide.yaml file and attempt to use an operation that uses data from glide.lock before running glide update you’ll be notified.

We recommend committing the glide.lock file to version control.

glide install

The install command used to be an alias to the update command. Not anymore.

Running glide install will now use the information in the glide.lock file to fetch the dependencies and set the appropriate version. Because it doesn’t need detect the dependency tree and with the use of some new optimizations, such as using concurrency to fetch packages and set versions, this operation is much faster than an update.

When no glide.lock file is present the glide install command will run update.

Given this change in Glide we’re recommending using these new features any time you don’t need to update the dependency tree or its versions. This makes glide install ideal for continuous testing environments.