Dep: Lock mismatch when locked to a non-tip revision for a branch constraint

[carolynvs]

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

go version go1.8.3 darwin/amd64
v0.1.0-240-g6c5ebb9

What dep command did you run?

dep status

What did you expect to see?

PROJECT                CONSTRAINT     VERSION        REVISION  LATEST   PKGS USED
github.com/pkg/errors  branch master  branch master  ff09b13   c605e28  1

What did you see instead?

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

The output for dep hash-inputs is the same after I write a new lockfile by running dep ensure. I'm not sure what else is being looked at though to determine the hash.

-CONSTRAINTS-
github.com/pkg/errors
b-master
-IMPORTS/REQS-
github.com/pkg/errors
-IGNORES-
-OVERRIDES-
-ANALYZER-
dep
1

Configuration Files

main.go

package main

import _ "github.com/pkg/errors"

func main() {
}

Gopkg.toml

[[constraint]]
  branch = "master"
  name = "github.com/pkg/errors"

Gopkg.lock

[[projects]]
  name = "github.com/pkg/errors"
  packages = ["."]
  revision = "ff09b135c25aae272398c51a07235b90a75aa4f0"

[solve-meta]
  analyzer-name = "dep"
  analyzer-version = 1
  inputs-digest = "b9666cf94a3cd7bce37b6931b5321d3dbe1d07c0043886167c3b194453bcbec0"
  solver-name = "gps-cdcl"
  solver-version = 1

[sdboyer]

Easiest way to debug this will be to insert something that dumps gps.HashingInputsAsString() just before whichever inputs-hash comparison check is failing - that should give a more honest picture to compare against dep hash-inputs output.

[carolynvs]

Below is dep status for both cases, with the inputs printed. The strings are exactly the same.

$ dep status
-CONSTRAINTS-
github.com/pkg/errors
b-master
-IMPORTS/REQS-
github.com/pkg/errors
-IGNORES-
-OVERRIDES-
-ANALYZER-
dep
1

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

Run dep ensure to rewrite the lock then...

$ dep status
-CONSTRAINTS-
github.com/pkg/errors
b-master
-IMPORTS/REQS-
github.com/pkg/errors
-IGNORES-
-OVERRIDES-
-ANALYZER-
dep
1

PROJECT                CONSTRAINT     VERSION        REVISION  LATEST   PKGS USED
github.com/pkg/errors  branch master  branch master  c605e28   c605e28  1

[sdboyer]

🤦‍♂️ i'm not sure what the deal here would be...but status has been lacking love for a long time. i can look again more seriously after #489, and then @darkowlzz and i can hopefully get things like this squared away.

[darkowlzz]

@carolynvs Your initial lock file does not contain branch.

[[projects]]
  name = "github.com/pkg/errors"
  packages = ["."]
  revision = "ff09b135c25aae272398c51a07235b90a75aa4f0"

Usually when branch is specified in manifest, the generated lock includes branch name too. I think that's causing this issue.

I created Gopkg.toml:

[[constraint]]
  name = "github.com/pkg/errors"
  branch = "master"

and Gopkg.lock:

[[projects]]
  branch = "master"
  name = "github.com/pkg/errors"
  packages = ["."]
  revision = "ff09b135c25aae272398c51a07235b90a75aa4f0"

[solve-meta]
  analyzer-name = "dep"
  analyzer-version = 1
  inputs-digest = "a5785f91e34c6888b78d77a1937bcd00ba051ca6e3927b0b9a119bcbf5a1a325"
  solver-name = "gps-cdcl"
  solver-version = 1

The input-digest seems to be different from the one you posted. Maybe because of the branch constraint.

If I edit manifest to

[[constraint]]
  name = "github.com/pkg/errors"
  revision = "ff09b135c25aae272398c51a07235b90a75aa4f0"

and run ensure, then I get the same input-digest as you posted above, b9666cf94a3cd7bce37b6931b5321d3dbe1d07c0043886167c3b194453bcbec0.

So, maybe your lock was created with revision locked, not branch.

[carolynvs]

The lock got in that state after running dep ensure github.com/pkg/errors@ff09b135c25aae272398c51a07235b90a75aa4f0.

Now that ensure has been rewritten, I'm not even sure this is a valid bug anymore. Can you specify a specific version/branch/revision anymore during dep ensure -update?

[sdboyer]

gonna close this out - we can reopen if it turns out to be valid in the new ensure world.