Semantics for "check if imports/Gopkg.toml are in sync with Gopkg.lock" command

[sdboyer]

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.

[JelteF]

I think it would make sense to have it in dep ensure, currently the -dry-run flag also doesn't perform any writes. It would basically be dep ensure -dry-run --no-vendor with an returning an error code when it would normally start solving. Maybe dep status would also be ok, but it seems to have to do with other status stuff mostly at the moment (and it seems really unfinished). Option 3 seems overkill to me.

I'm not entirely sure tho -check-sync name is the best name for the flag though.

[sdboyer]

It would basically be dep ensure -dry-run --no-vendor with an returning an error code when it would normally start solving.

mmm, this is another interesting option - we could, at least as a temporary measure, detect these two flags in combination and exit non-zero if things are out of sync. it's a bit magic, but it lets us avoid having to introduce new semantics, and i can't think of any other reason to run with these flags in combination, so it wouldn't be displacing anything.

i think i'm 👍 to that 😄 just need to merge #489 now!

[JelteF]

It's indeed a bit magic, but I think it would be fine if documented. The only downside I can think of is that you won't know if the solving would be successful, if tried non dry. However, if you want that you can just do dep ensure -dry-run (without -no-vendor) and it won't be any slower.

[sdboyer]

However, if you want that you can just do dep ensure -dry-run (without -no-vendor) and it won't be any slower.

exactly - -dry-run itself implies -no-vendor, so we can make including that flag explicitly have this additive meaning.

[smyrman]

For CI's, other build tools and Makefile alternatives, it wold be really cool if you could check (really fast, without going to the network), not only if imports/Gopkg.toml are in sync with Gopkg.lock, but also if vendor is in sync with Gopkg.lock. Preferably via the exit code rather that output inspection. Is this also part of this?

To me, this kind of sounds like a status flag, but I guess ensure could work as well. The usage would really be to know if dep ensure will perform any changes or not (and thus know if you should run dep ensure and all dependant operations).

[sdboyer]

@smyrman 💯 💯 💯 . that's what #121 is about, and we're making good progress in #959 😄

that's largely orthogonal to this issue, though.