Migrating from Glide to dep

golang package management

May 26, 2018

Package management is a bread-and-butter task. Rarely does a Go developer write a Go program that doesn’t reference an external package. Over the course of the years, the Go community has seen various approaches to solving the same problem. From go get over vendoring to package managers like Glide. Each solution comes with its benefits and drawbacks.

Recently, the Go community settled on dep as the canonical tool for package management. In this blog post, I am going to describe the migration path from Glide to dep. Versioned Go aka vgo, the proposed next generation of package management, will be neglected in this post. I am planning to write up a more detailed blog post on vgo later.

Using Glide: The "old" world

Glide has been around for a couple of years. Coming from Java using Glide made me feel right at home. In Glide, you have a definition file that describes your versioned dependencies either for your production source code or your test source code. This file is called glide.yaml. In listing 1 you can see an example for such a file.


package: .
- package: github.com/mvdan/xurls
  version: 1.1.0
- package: github.com/stretchr/testify
  version: 1.1.4

Listing 1. Glide package definition

It’s a good idea to lock down your dependency versions and their transitive dependencies to ensure reproducibility for the build. Glide takes care of this aspect by generating a lock file. The lock file named glide.lock pins each package to the commit hash of a specific dependency. Listing 2 shows the locked versions of the packages declared in the previous example.


hash: 806deb3bb1bb02051f152c49856cac37224f623247742a1b8c028b38dff21aef
updated: 2018-01-08T20:54:38.326434-07:00
- name: github.com/mvdan/xurls
  version: d315b61cf6727664f310fa87b3197e9faf2a8513
- name: github.com/davecgh/go-spew
  version: 6d212800a42e8ab5c146b8ace3490ee17e5225f9
  - spew
- name: github.com/pmezard/go-difflib
  version: d8ed2627bdf02c080bf22230dbb337003b7aba2d
  - difflib
- name: github.com/stretchr/testify
  version: 69483b4bd14f5845b5a1e55bca19e954e827f1d0
  - assert

Listing 2. Locked package versions in Glide

The command glide install reads the lock file and installs each package with the denoted commit ID into the vendor directory. With the lock file in place, the source code can be built at any given time without the risk of packages silently changing the API underneath and breaking the build.

Glide discontinued its development efforts in favor of dep. It’s highly recommended to migrate the dependency definitions. Let’s see how this can be achieved with the built-in tooling of dep.

Generating dep files

Dep comes with a convenient command for deriving dependency definitions from Glide files and turns them into instructions it can understand. This command is called init. Below you can find the console output generated by running dep init from the directory containing the Glide files.

$ dep init
Importing configuration from glide. These are only initial constraints, and are further refined during the solve process.
Detected glide configuration files...
Converting from glide.yaml and glide.lock...
  Using ^1.1.0 as initial constraint for imported dep github.com/mvdan/xurls
  Trying v1.1.0 (d315b61) as initial lock for imported dep github.com/mvdan/xurls
  Using ^1.1.4 as initial constraint for imported dep github.com/stretchr/testify
  Trying v1.1.4 (69483b4) as initial lock for imported dep github.com/stretchr/testify
  Trying * (6d21280) as initial lock for imported dep github.com/davecgh/go-spew
  Trying * (d8ed262) as initial lock for imported dep github.com/pmezard/go-difflib
Old vendor backed up to /Users/bmuschko/go/src/github.com/bmuschko/link-verifier/_vendor-20180517161351

As a result, dep generates the file Gopkg.toml, its own dependency definition format. You will find it contains the exact same packages you had declared in the Glide file.


  name = "github.com/mvdan/xurls"
  version = "1.1.0"

  name = "github.com/stretchr/testify"
  version = "1.1.4"

  go-tests = true
  unused-packages = true

Listing 3. Package definitions in dep

The migration command also generated a dep lock file. Run the command dep ensure to produce the vendor files. You can now delete the Glide files and check in the new files into version control. Migration done!


  name = "github.com/davecgh/go-spew"
  packages = ["spew"]
  revision = "6d212800a42e8ab5c146b8ace3490ee17e5225f9"

  name = "github.com/mvdan/xurls"
  packages = ["."]
  revision = "d315b61cf6727664f310fa87b3197e9faf2a8513"
  version = "v1.1.0"

  name = "github.com/pmezard/go-difflib"
  packages = ["difflib"]
  revision = "d8ed2627bdf02c080bf22230dbb337003b7aba2d"

  name = "github.com/stretchr/testify"
  packages = ["assert"]
  revision = "69483b4bd14f5845b5a1e55bca19e954e827f1d0"
  version = "v1.1.4"

  analyzer-name = "dep"
  analyzer-version = 1
  inputs-digest = "dc6228ad4f235c0b15f417683e0556d99443a9231695bf8cbad5239062df2aac"
  solver-name = "gps-cdcl"
  solver-version = 1

Listing 4. Locked package versions in dep

Next, you will learn how to enable and use dep integration in an IDE. For this purpose, we’ll have a look at GoLand, JetBrains' premiere Go tooling support.

Using dep in the IDE

GoLand is my preferred IDE for Go projects. It has the same look & feel as IDEA, the Java tooling from JetBrains. You should feel right at home if you are familiar with any of their products.

Enabling dep integration

Dep received first-class support in GoLand. To configure and enable dep integration go to the menu option GoLand > Preferences…​ > Go > Dep. Simply point to the dep executable and enable the tooling as shown in figure 1.

goland enabled dep integration

Figure 1. Enabling dep integration in Goland

Resolving dependencies

goland vendor directory

At the time of writing, GoLand does not automatically resolve dependencies even if dep integration has been enabled. You will have to run dep ensure from the command line or click on the link "Run dep ensure" in the "Event log" proposed by Goland. You should see the vendor directory rendered in figure 2 as soon as you select one of the options.

Any further action in the IDE uses the dependencies in the vendor directory. From now on, you can run/debug the program or execute tests.

comments powered by Disqus