Go latest DEP detailed

This is a creation in Article, where the information may have evolved or changed.

This article is translated from https://medium.com/i-can-haz-downtime/dep-101-c85e8ab6ed45#.hbngswi0e

I am delighted that in the past few months and several other gopher developed a prototype that relies on administrative tools, called Dep.

DEP was part of a project started last year by Peter Bourgon. Since I was involved in developing a "GODEP", Go's OG relies on management tools (inherited from Keith Rarick), so I joined the DEP project team.

In addition to myself and Peter, the other members of the team are Jessie Frazelle,andrew Gerrand and Sam Boyer. Andrew is a member of the Google Go team. Jessie works for Google and participates in large go projects such as Docker and Kubernetes. Sam maintains GPS.

The team released a series of information about the progress of our work. So far, a variety of other tool authors and stakeholders have participated in this project in different ways.

Initially

Let's say we're writing a Web application using Github.com/gorilla/mux. Here's some code, let's get started:

package mainimport (    "net/http"    "os"    "github.com/gorilla/mux")func main() {    r := mux.NewRouter()    r.Handle("/", http.FileServer(http.Dir(".")))    http.ListenAndServe(":"+os.Getenv("PORT"), r)}

When you use DEP for the first time on an existing project, you need to run DEP init.

DEP Init will include it in Gopath that already contains the Github.com/gorilla/mux,manifest.json file. Let me run the following command:

go get -u github.com/gorilla/mux

So the Github.com/gorilla/mux branch in my $gopath is master. If the version in my $gopath matches the semver tag (for example: v1.2.3), then the tag name will be used.

DEP can span schemas and go versions. We can use Github.com/gorilla/mux with the old version of Go (<1.7.0) Github.com/gorilla/context package. When I finally run

go get -u github.com/gorilla/mux

, I am running go 1.7.5, so the Github.com/gorilla/context package is not in my $gopath. It is included in the Lock.json file because it may be the dependency required to compile the project. In this scenario, if the dependent project has a semver compatible release TAG,DEP, the latest version is selected. In this case is the v1.1 of the Github.com/gorilla/context.

Because Github.com/gorilla/mux does not contain manifest.json files, DEP does not know if Github.com/gorilla/mux is currently able to work with github.com/gorilla/context@v1.1. DEP generally uses constraints found in dependent Manifest.json files.

DEP init includes all dependencies (including recursive dependencies) and the exact version used in the Lock.json file.

For a sample application, this creates the following two files:
Lock.json

{    "Memo": "D741a3bed21fe6cae9d67c523b0a343859882b2f246f2a293e2676cfacd5a2ce",     "projects": [       {            ' name ': ' Github.com/gorilla/context ',   &nbsp ;         "version": "v1.1",      ,       "revision": "A85d2e53ba63bdea074db bbb5983f0516974e87b ",            " packages ": [            &NB Sp   "."            ]        },        {  &NB Sp          "name": "Github.com/gorilla/mux",      ,       "branch": "Master",             "revision": "392c28fe23e1c45ddba891b0320b3b5df220beea",       &N Bsp     "Packages": [                "."           & nbsp;]   &NBSP    }    ]}

Manifest.json

{    "dependencies": {        "github.com/gorilla/mux": {            "branch": "master"        }    }}

Make sure the project can be compiled

After you run DEP init, you should run DEP ensure to populate the vendor/directory with a copy of the package that you need to build your project. This ensures that any project dependencies are included in the lock file and in the vendor directory. If you want to make sure that all dependencies are logged, run DEP ensure.

Add dependency

Add another dependency, just use it in your code. When you need to check your work, you need to run DEP ensure update Lock.json files and vendor/. This locks the project to the latest release version of each dependency.

What if the latest version doesn't fit?

If you need to specify a version, you can use the alternate form of the ensure command, such as DEP ensure github.com/gorilla/mux@\^1.3.0. This command modifies the Manifest.json file, which constrains DEP to use the \^v1.3.0 version of Github.com/gorilla/mux, resolves the dependency tree, and updates the dependencies in vendor/. On the sample application, because DEP has selected the latest available version of 1.3.0. However, later updates (DEP ensure-update) will no longer track the main branch, but instead use the version ≥1.3.0 and <2.0.0 of the semver tag.

DEP mainly uses rust cargo similar operators to select dependent versions. These include \^,~ and =. There is also a stricter, forward compatible match than \^ use ~. For example, DEP ensures that github.com/com/gorilla/mux@~1.2.0 will match greater than or equal to 1.2.0 and less than 1.3.0 any version. To lock to a specific version, use = (e.x. DEP ensure github.com/com/gorilla/mux@=1.2.0). In the future, DEP plans to use \^ as the default prefix.

Keep up to date

To keep your project dependencies up-to-date with DEP ensure-update, it updates all dependencies to the latest version allowed by the constraints in Manifest.json and ignores Lock.json content. Writes the new version to vendor/and updates the corresponding metadata in the Lock.json.
In the future, you can update individual dependencies with DEP ensure-update.

Status

When a dependency is missing, the DEP status tells you which packages are missing. For example, here is the output of DEP status:

$ dep statusPROJECT                 MISSING PACKAGESgithub.com/boltdb/bolt  [github.com/boltdb/bolt]

If the project's Lock.json is up-to-date, the DEP status command displays a list of all dependencies, as items, and for each:

• Apply constraint

• Select version

• Selected revision

• Latest Version or revision

• The number of packages used. After the
  adds bolts to the sample project and runs DEP, make sure that the update Lock.json and VENDOR/,DEP status are as follows:

$ dep statusproject CONSTRAINT VERSION REVISION LATEST pkgs Usedgithub.com/boltdb/bolt     * v1.3.0 583e893 v1.3.0 1github.com/gorilla/context * v1.1 a85d2e5 v1.1  1github.com/gorilla/mux ^1.3.0 v1.3.0 392c28f v1.3.0 1golang.org/x/sys * Branch Master 7a6e564 7a6e564 1

Both of these modes can be merged in the future.

Remove dependencies

DEP remove removes dependencies from Manifest.json,lock.json and vendor/. Using the sample application, this commit removes the use of Github.com/gorilla/mux from the application, and the next commit is the result of DEP remove Github.com/gorilla/mux. Because Github.com/gorilla/mux is removed, Github.com/gorilla/context is no longer needed and will be deleted. If you still use a dependency when you run DEP remove, the command will fail. You can use-force to force the removal of constraints from Manifest.json. However, because the dependency is still in use, it is still in Lock.json and copied to vendor/.

Future

DEP is still in the experimental phase, with many issues to be addressed and much work to be done. I hope this article clearly shows some examples of how to use tools. Usage may change over time through community feedback and requests. If you have some free time and are interested in some go tool development, please start now.
Thank you for reading!