dep ensure give completely different package resolution before and after removing Gopkg.lock

[HaraldNordgren]

I had a merge conflict affecting both Gopkg.toml and Gopkg.lock, so I decided to remove the lock file and run ensure to start fresh.

I got a completely different resolution of packages from dep ensure before and after. It didn't seem to respect versions for example. Is this expected?

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

 % dep version
dep:
 version     : devel
 build date  :
 git hash    :
 go version  : go1.8.3
 go compiler : gc
 platform    : darwin/amd64

What dep command did you run?

dep ensure

[darkowlzz]

@HaraldNordgren thanks for creating an issue to discuss this.

As described in the FAQ:

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.

Gopkg.toml, the manifest, contains flexible constraints about your dependencies. They are not locked down to any specific revision, usually. Hence, running ensure at different point in time would result in different resolutions, but under the defined constraints.

dep performs code analysis and finds all the dependencies, even the ones you don't explicitly define in Gopkg.toml. So it's possible to have some of the dependencies to not be in Gopkg.toml but in Gopkg.lock. This is because Gopkg.toml is supposed to be manually maintained. You define constraint for a dependency in Gopkg.toml for safety and it's optional.

So, yes, it's expected to see different resolution if you remove the lock, in certain situations based on your Gopkg.toml. If you think there's a bug, in resolving the dependencies which are defined in your Gopkg.toml, it would be great have more details about your dependencies and what differences you get with and without the lock.

Hope this helps!

[sdboyer]

hi, welcome!

so, it's a "yes" and "no," here. this:

I got a complete different resolution of packages from dep ensure before and after.

is 💯 normal. dep ensure's default behavior is to be as conservative as possible, by preserving whatever is in Gopkg.lock. when you get rid of Gopkg.lock, there's no longer anything to preserve, so it goes back to the same behavior you'd see with dep ensure -update - basically, get the latest that are allowed by constraints. to that end, this:

It didn't seem to respect versions for example.

would not be expected, but i suspect that what's actually going on is that dep init converted you pretty smoothly, so you're now encountering one of two things for the first time:

1. [[constraint]]s only affect your direct dependencies. (Report when manifests contain ineffectual constraints #302 is open with the goal of informing people when they have ineffectual dependencies)
2. version = "1.0.0" is interpreted as having a leading ^, which actually makes it a range, rather than an exact match. See the note in the semver section of the README.