dep ensure: must provide a lock in order to write out vendor

[peterbourgon]

I have a repo with a manifest and lock and as part of my CI run I do a plain dep ensure from the repo root. Worked great until it didn't, change in the last ~36 hours:

$ go get github.com/golang/dep/cmd/dep
$ dep ensure
grouped write of manifest, lock and vendor: must provide a lock in order to write out vendor

[sdboyer]

Huh. Weird. Yeah, that's a bug for sure. I bet we missed a path in #256, and/or in the new test harness, too. ping @carolynvs @tro3 - thoughts? 😄

[carolynvs]

This is probably related to my PR that was just merged, as it touched the safe writer which is printing that message. Looking now.

[tro3]

Sounds like a test case should be added to cover this, once found. The coverage is not expansive right now, as changes in behavior are looming.

[carolynvs]

The test was there but I had misunderstood when both lock and newlock should be set in the tests, so it wasn't correctly testing the scenario.

[gregory-m]

Any plans on fixing this.
BWT the bug was introduced in e43a3b8.

Also can you please collaborate on you bug fixing policy.

I fully understand its Alpha and I'am using it on my own risk.
But on other hand this bug broke CI for 2 days for all people who volunteered to test dep on their CI environments.

Thanks.

EDIT: In replay to downvote.

I don't blame anyone, and respect everyones effort to solve go dependencies management problem.

I just trying to understand if it was good idea to try dep in one of our internal projects.
And if it wasn't good idea, then I can try it one more time.

[carolynvs]

The fix is being worked on in this PR: #325.

[sdboyer]

@gregory-m at this point, you absolutely shouldn't be relying on dep for anything in real, production infrastructure. What we're asking people for is to test drive it - attempt initial conversions, build out an alternate pipeline in their CI infrastructure, etc.

While we obviously have no intention of breaking tip, or leaving it that way for any extended period, we also need to not be unduly afraid of doing so. There's still too many open questions.

[gregory-m]

@sdboyer Thanks.

Will commit vendor, and create separate build to continue report bugs.

[sdboyer]

@gregory-m that's the best response i could've hoped for from that - thank you! keeping a build pipeline open on the side is tremendously helpful to our efforts here. 🎉 🎉