Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

Lock mismatch immediately after dep init #917

Closed
carolynvs opened this issue Jul 27, 2017 · 1 comment · Fixed by #1099
Closed

Lock mismatch immediately after dep init #917

carolynvs opened this issue Jul 27, 2017 · 1 comment · Fixed by #1099

Comments

@carolynvs
Copy link
Collaborator

carolynvs commented Jul 27, 2017

What version of Go (go version) and dep (git describe --tags) are you using?

$ go version
go version go1.8.3 darwin/amd64

$ git describe --tags
v0.1.0-295-gd558b52

What dep command did you run?

dep init && dep status

What did you expect to see?

I expected that after a fresh init and no changes, that the lock would be valid.

What did you see instead?

Lock inputs-digest mismatch. This happens when Gopkg.toml is modified.
Run `dep ensure` to regenerate the inputs-digest.

I believe the problem is that when we run dep init, it detects external tools and sets the analyzer name to dep+import. When dep ensure is run, it doesn't use any importers so the analyzer name is just dep, immediately triggering a lock mis-match.

We will eventually run the analyzers during ensure, #821. Once we have that in place and both init and ensure use the importers, the hash won't mismatch.

@sdboyer
Copy link
Member

sdboyer commented Jul 31, 2017

in general, the purpose of that field (along with the associated version number) is to uniquely identify a particular analyzer algorithm. if the algorithm is actually the same, depending on some configuration (e.g., use the external tools importers or don't), then there's no need for the name to be any different.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
2 participants