Semantics for "check if imports/Gopkg.toml are in sync with Gopkg.lock" command #950
Description
Many of our commands pay careful attention to whether the import set + Gopkg.toml are in sync with Gopkg.lock, and vary their behavior accordingly. That's that first step in the state sync diagram:
However, we do not currently expose any way of just checking if this relationship is intact to the user - it's always implicit in some other action. That makes it hard to, say, check that they're in sync during a CI process.
Actual implementation here is pretty simple, but I've been stuck on what the right semantics of this are for a while. I can imagine three basic options:
Option 1: A new flag to dep ensure, e.g. dep ensure -check-sync
This is probably the easiest to implement, but it's also arguably against the spirit of ensure, being that there is no situation in which it actually performs writes. This is my least preferred solution, but it's possible my preference arises from having too much knowledge of the inner workings - users with a black box perspective might have a different take.
Option 2: A new flag to dep status, e.g. dep status -verify
The big issue here is that this check the basic "sync" check we do is entirely symbolic. There are additional layers of verification that will ultimately be important to implement: have any upstream sources gone away? have any upstream references moved unexpectedly, or gone away? are there security notices for any of the versions in our Gopkg.lock?
My main concern here is that these really are separate use cases, and should probably have separate flags - but i don't want to bloat dep status too much.
Option 3: A new command, dep verify
The possible goals for verification are the same as described in the previous option, but there's less of a concern over multiple interrelated flags (if that's even a good idea). The only real drawback here is expanding the command set, which could complicate moving into the toolchain.