Dep: Ensure Paradox

Created on 18 Aug 2017  路  3Comments  路  Source: golang/dep

Using: go1.8.3 windows/amd64 and latest dep

When I use dep ensure -add <package> followed by another I get the following messages:

> dep ensure -add google.golang.org/grpc
"google.golang.org/grpc" is not imported by your project, and has been temporarily added to Gopkg.lock and vendor/.
If you run "dep ensure" again before actually importing it, it will disappear from Gopkg.lock and vendor/.

> dep ensure -add github.com/golang/protobuf/protoc-gen-go
Gopkg.toml and Gopkg.lock are out of sync. Run a plain dep ensure to resync them before attempting to -add

So now, I cannot add another package before running ensure but if I run the ensure my previous package will be erased. When bootstrapping a project, I want to be able to binge install packages before I get started.

Why is this the default behavior? I can just do something like dep clean if I want to cleanup referenced packages.

Most helpful comment

@sdboyer Thanks for the quick reply and explanation! The workarounds and ideas/concepts you mentioned are fair enough :)

Keep up the great work!

All 3 comments

hi, welcome! thanks for the issue 馃槃

yeah, this is the main way in which dep is highly opinionated. simplest workaround - if binging is the goal, you can throw them all in together on one line:

dep ensure -add google.golang.org/grpc github.com/golang/protobuf/protoc-gen-go

though i understand that often binging involves firing off that command a bunch of times as things occur to you. which, yeah, we don't support.

an alternative is adding the set of packages you know you want to the required list in Gopkg.toml. that'll make them persist across dep ensure runs, and you won't get the out-of-sync complaints.

Why is this the default behavior? I can just do something like dep clean if I want to cleanup referenced packages.

there is no dep clean 馃槃 to the extent that there is such a concept, it's an inseparable part of dep ensure. dep doesn't let unused state hang around on disk in this way, because almost all of the time, it's just extra bookkeeping, extra steps in code review, extra CI, etc. in general, it removes ambiguity from the system, allowing a much tighter model and set of tool behaviors.

@sdboyer Thanks for the quick reply and explanation! The workarounds and ideas/concepts you mentioned are fair enough :)

Keep up the great work!

@cemremengu thanks!

Was this page helpful?
0 / 5 - 0 ratings