You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 9, 2020. It is now read-only.
Copy file name to clipboardExpand all lines: docs/FAQ.md
+42-18
Original file line number
Diff line number
Diff line change
@@ -37,6 +37,7 @@ Summarize the question and quote the reply, linking back to the original comment
37
37
*[My dependers don't use `dep` yet. What should I do?](#my-dependers-dont-use-dep-yet-what-should-i-do)
38
38
*[How do I configure a dependency that doesn't tag its releases?](#how-do-i-configure-a-dependency-that-doesnt-tag-its-releases)
39
39
*[How do I use `dep` with Docker?](#how-do-i-use-dep-with-docker)
40
+
*[How do I use `dep` in CI?](#how-do-i-use-dep-in-ci)
40
41
41
42
## Concepts
42
43
### Does `dep` replace `go get`?
@@ -49,12 +50,12 @@ Here are some suggestions for when you could use `dep` or `go get`:
49
50
> `go get`: I want to download the source code for a go project so that I can work on it myself, or to install a tool. This clones the repo under GOPATH for all to use.
50
51
>
51
52
> `dep ensure`: I have imported a new dependency in my code and want to download the dependency so I can start using it. My workflow is "add the import to the code, and then run dep ensure so that the manifest/lock/vendor are updated". This clones the repo under my project's vendor directory, and remembers the revision used so that everyone who works on my project is guaranteed to be using the same version of dependencies.
52
-
>
53
+
>
53
54
> [@carolynvs in #376](https://github.com/golang/dep/issues/376#issuecomment-293964655)
54
55
55
56
> The long term vision is a sane, overall-consistent go tool. My general take is that `go get`
56
57
> is for people consuming Go code, and dep-family commands are for people developing it.
57
-
>
58
+
>
58
59
> [@sdboyer in #376](https://github.com/golang/dep/issues/376#issuecomment-294045873)
59
60
60
61
### Why is it `dep ensure` instead of `dep install`?
@@ -64,7 +65,7 @@ Here are some suggestions for when you could use `dep` or `go get`:
64
65
> The idea of "ensure" is roughly, "ensure that all my local states - code tree, manifest, lock, and vendor - are in sync with each other." When arguments are passed, it becomes "ensure this argument is satisfied, along with synchronization between all my local states."
65
66
>
66
67
> We opted for this approach because we came to the conclusion that allowing the tool to perform partial work/exit in intermediate states ended up creating a tool that had more commands, had far more possible valid exit and input states, and was generally full of footguns. In this approach, the user has most of the same ultimate control, but exercises it differently (by modifying the code/manifest and re-running dep ensure).
67
-
>
68
+
>
68
69
> [@sdboyer in #371](https://github.com/golang/dep/issues/371#issuecomment-293246832)
69
70
70
71
### What is a direct or transitive dependency?
@@ -77,7 +78,7 @@ Here are some suggestions for when you could use `dep` or `go get`:
77
78
> The manifest describes user intent, and the lock describes computed outputs. There's flexibility in manifests that isn't present in locks..., as the "branch": "master" constraint will match whatever revision master HAPPENS to be at right now, whereas the lock is nailed down to a specific revision.
78
79
>
79
80
> This flexibility is important because it allows us to provide easy commands (e.g. `dep ensure -update`) that can manage an update process for you, within the constraints you specify, AND because it allows your project, when imported by someone else, to collaboratively specify the constraints for your own dependencies.
80
-
>
81
+
>
81
82
> [@sdboyer in #281](https://github.com/golang/dep/issues/281#issuecomment-284118314)
82
83
83
84
## How do I constrain a transitive dependency's version?
@@ -113,7 +114,7 @@ No.
113
114
114
115
> Placing these files inside `vendor/` would concretely bind us to `vendor/` in the long term.
115
116
> We prefer to treat the `vendor/` as an implementation detail.
116
-
>
117
+
>
117
118
> [@sdboyer on go package management list](https://groups.google.com/d/msg/go-package-management/et1qFUjrkP4/LQFCHP4WBQAJ)
118
119
119
120
## How do I get dep to authenticate to a git repo?
@@ -243,7 +244,7 @@ Unable to update checked out version: fatal: reference is not a tree: 4dfc6a8a7e
243
244
> The lock file represents a set of precise, typically immutable versions for the entire transitive closure of dependencies for a project. But "the project" can be, and is, decomposed into just a bunch of arguments to an algorithm. When those inputs change, the lock may need to change as well.
244
245
>
245
246
> Under most circumstances, if those arguments don't change, then the lock remains fine and correct. You've hit one one of the few cases where that guarantee doesn't apply. The fact that you ran dep ensure and it DID a solve is a product of some arguments changing; that solving failed because this particular commit had become stale is a separate problem.
246
-
>
247
+
>
247
248
> [@sdboyer in #405](https://github.com/golang/dep/issues/405#issuecomment-295998489)
248
249
249
250
## Why is `dep` slow?
@@ -299,10 +300,10 @@ This is the only symbolic link support that `dep` really intends to provide. In
299
300
300
301
No.
301
302
> dep simply doesn't allow relative imports. this is one of the few places where we restrict a case that the toolchain itself allows. we disallow them only because:
302
-
>
303
+
>
303
304
> * the toolchain already frowns heavily on them<br>
304
305
> * it's worse for our case, as we start venturing into [dot dot hell](http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames) territory when trying to prove that the import does not escape the tree of the project
305
-
>
306
+
>
306
307
> [@sdboyer in #899](https://github.com/golang/dep/issues/899#issuecomment-317904001)
307
308
308
309
For a refresher on Go's recommended workspace organization, see the ["How To Write Go Code"](https://golang.org/doc/code.html) article in the Go docs. Organizing your code this way gives you a unique import path for every package.
@@ -315,7 +316,7 @@ found in `GOPATH`. `dep ensure` doesn't work with projects in `GOPATH`.
315
316
316
317
## Will `dep` let me use git submodules to store dependencies in `vendor`?
317
318
318
-
No, with just one tiny exception: `dep` preserves `/vendor/.git`, if it exists. This was added at [cockroachdb](https://github.com/cockroachdb/cockroach)'s request, who rely on it to keep `vendor` from bloating their primary repository.
319
+
No, with just one tiny exception: `dep` preserves `/vendor/.git`, if it exists. This was added at [cockroachdb](https://github.com/cockroachdb/cockroach)'s request, who rely on it to keep `vendor` from bloating their primary repository.
319
320
320
321
The reasons why git submodules will not be a part of dep are best expressed as a pro/con list:
321
322
@@ -427,19 +428,42 @@ This is especially useful for builds inside docker utilizing cache layers.
427
428
428
429
Sample dockerfile:
429
430
430
-
FROM golang:1.9 AS builder
431
+
```Dockerfile
432
+
FROM golang:1.9 AS builder
431
433
432
-
RUN curl -fsSL -o /usr/local/bin/dep https://github.com/golang/dep/releases/download/vX.X.X/dep-linux-amd64 && chmod +x /usr/local/bin/dep
434
+
RUN curl -fsSL -o /usr/local/bin/dep https://github.com/golang/dep/releases/download/vX.X.X/dep-linux-amd64 && chmod +x /usr/local/bin/dep
433
435
434
-
RUN mkdir -p /go/src/github.com/***
435
-
WORKDIR /go/src/github.com/***
436
+
RUN mkdir -p /go/src/github.com/***
437
+
WORKDIR /go/src/github.com/***
436
438
437
-
COPY Gopkg.toml Gopkg.lock ./
438
-
# copies the Gopkg.toml and Gopkg.lock to WORKDIR
439
+
COPY Gopkg.toml Gopkg.lock ./
440
+
# copies the Gopkg.toml and Gopkg.lock to WORKDIR
439
441
440
-
RUN dep ensure -vendor-only
441
-
# install the dependencies without checking for go code
442
+
RUN dep ensure -vendor-only
443
+
# install the dependencies without checking for go code
442
444
443
-
...
445
+
...
446
+
```
447
+
448
+
## How do I use `dep` in CI?
449
+
450
+
Since `dep` is expected to change until `v1.0.0` is released, it is recommended to rely on a released version.
451
+
You can find the latest binary from the [releases](https://github.com/golang/dep/releases) page.
0 commit comments