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.