Migrating from Glide to dep

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.

glide.yaml

package: .
import:
- package: github.com/mvdan/xurls
  version: 1.1.0
testImport:
- 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.

glide.lock

hash: 806deb3bb1bb02051f152c49856cac37224f623247742a1b8c028b38dff21aef
updated: 2018-01-08T20:54:38.326434-07:00
imports:
- name: github.com/mvdan/xurls
  version: d315b61cf6727664f310fa87b3197e9faf2a8513
testImports:
- name: github.com/davecgh/go-spew
  version: 6d212800a42e8ab5c146b8ace3490ee17e5225f9
  subpackages:
  - spew
- name: github.com/pmezard/go-difflib
  version: d8ed2627bdf02c080bf22230dbb337003b7aba2d
  subpackages:
  - difflib
- name: github.com/stretchr/testify
  version: 69483b4bd14f5845b5a1e55bca19e954e827f1d0
  subpackages:
  - 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.

Gopkg.toml

[[constraint]]
  name = "github.com/mvdan/xurls"
  version = "1.1.0"

[[constraint]]
  name = "github.com/stretchr/testify"
  version = "1.1.4"

[prune]
  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!

Gopkg.lock

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

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

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

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

[solve-meta]
  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.