Need clarity about if Gopkg.lock really locks down depenendencies

[markcampanelli-wf]

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

0.3.2 stable via brew

What dep command did you run?

dep ensure

What did you expect to see?

I expect dep ensure to always abide by versions called out in any pre-existing "Godep.lock" file, or at least to have a flag option that will ensure that the Godep.lock is fully respected and not changed by dep ensure. In this case, dep should fail with a non-zero error code instead of trying to update any dependencies to satisfy constraints.

What did you see instead?

It was not clear to me from the documentation what the behavior of dep is here.

[sdboyer]

would the changes introduced in #1256 be adequate for your purposes?

doesn't solve the docs problem, but it may at least check the box.

[markcampanelli-wf]

I think #1256 will work for now.

BTW, this is to ensure that audits of our committed Gopkg.lock file accurately reflect what is actually built in CI.

[FiloSottile]

I think that the option -vendor-only would also work here, and running -no-vendor -dry-run and exiting on failure is an alternative, if I understand correctly.

However, I agree that this should be very well documented: it is a very important security concern to make sure CI will not go and change the lock file. I am a bit unhappy that it's not the default behavior, because surely some people will miss it and get non-reproducible builds, but I see why it's not, I think.

[FiloSottile]

I just saw this proposal for dep-check, and since the document does not specify where to send feedback, I'm commenting on this issue as it's relevant.

• This is great, exactly what I wanted, and actually made me understand better the different checks, which the documentation for -no-vendor -dry-run -vendor-only did not
• This should really really really be part of dep (not sure if that's the intention already): if it's a separate tool a lot of people will not use it, calling dep ensure in CI instead, ending up with unreproducible builds and unreviewed code (😱)
• This should be featured prominently on README and --help, for the same reason as above
• I'm still unclear on if there's a way to already do these dry checks with a combination of -no-vendor -dry-run -vendor-only

@sdboyer

[sdboyer]

yeah sorry, I didn't think to create a venue for feedback beyond comments directly on the doc. I can/should probably put it on the pm mailing list, too.

I'm fine with making it another dep subcommand, rather than being a standalone tool.

there isn't a way of doing quite exactly the same thing with ensure flags; doing so would be overloading ensure too much, as the purpose of ensure is to rely on these checks as a prerequisite to doing its work, not just do the checks themselves. (that one weird flag combo was always kind of a hack - some kind of checker like this has always been my intent)