dep ensure doesn't always seem to ensure that lock file holds all deps

[rogpeppe]

What version of dep are you using (dep version)?

v0.3.2-161-ga926781

What dep command did you run?

dep ensure -no-vendor

What did you expect to see?

I expected to see the Gopkg.lock updated to the latest compatible version for all dependencies, and that it would have an entry for all dependencies that are in the project.

What did you see instead?

% dep ensure -v -no-vendor
Gopkg.lock was already in sync with imports and Gopkg.toml
% find . -name '*.go' | xargs grep bakery.v2
./config/config.go:	"gopkg.in/macaroon-bakery.v2/bakery"
./config/config_test.go:	"gopkg.in/macaroon-bakery.v2/bakery"
./internal/server/common_test.go:	"gopkg.in/macaroon-bakery.v2/httpbakery"
./internal/server/error.go:	"gopkg.in/macaroon-bakery.v2/httpbakery"
./internal/server/server_test.go:	"gopkg.in/macaroon-bakery.v2/bakery"
./internal/server/server.go:	"gopkg.in/macaroon-bakery.v2/bakery"
./internal/server/server.go:	"gopkg.in/macaroon-bakery.v2/httpbakery"
./internal/server/auth.go:	"gopkg.in/macaroon-bakery.v2/bakery"
./internal/server/auth.go:	"gopkg.in/macaroon-bakery.v2/bakery/identchecker"
./internal/server/auth.go:	"gopkg.in/macaroon-bakery.v2/httpbakery"
./internal/store/store.go:	"gopkg.in/macaroon-bakery.v2/bakery"
./internal/store/store.go:	"gopkg.in/macaroon-bakery.v2/bakery/postgresrootkeystore"
./cmd/azure-ua/main.go:	"gopkg.in/macaroon-bakery.v2/bakery"
% grep bakery Gopkg.lock
% grep bakery Gopkg.toml
  name = "gopkg.in/macaroon-bakery.v2"
% ed Gopkg.toml
1678
$-3,$p

[[constraint]]
  branch = "v2"
  name = "gopkg.in/macaroon-bakery.v2"
q
%

In case it makes a difference, I had accidentally run dep ensure previously (forgetting to use the -no-vendor flag), and then manually did rm -r vendor to remove the unwanted vendor directory.

[rogpeppe]

Removing the lock file and running dep ensure -no-vendor again did populate the lock file correctly FWIW.

[sdboyer]

huh. weird. the most concerning thing here is that dep seems to think the lock was in sync, even though it was lacking some items.

is there any chance the lock was the product of a merge, and thus the value of inputs-digest was not actually one that corresponded to the lock's other contents? something like that is the easiest way to imagine this happening.

[rogpeppe]

It is entirely possible that I encountered this issue after doing a rebase, though I can't be sure. Given that merge/rebase is a very common operation, I would hope that dep would still cope - doesn't the input digest include a hash of all the files in the repo?

[sdboyer]

the inputs-digest is more restrictive than that, or it'd be changing constantly - run dep hash-inputs | tr -d "\n" | shasum -a256, and you'll see something familiar.

it's actually not necessary to store the inputs-digest at all, and doing so is producing erroneous conflicts - #1224. relying on it also allows issues like this to occur, because we're checking the inputs-digest field instead of just checking the actual data in Gopkg.lock, which is really negligibly less expensive to do.

so yeah, it's slated to go away entirely and be replaced by more robust checking routines, which will also address whatever underlying issue you had here - dep will no longer be able to be duped about whether or not Gopkg.lock is in sync.