Add --dry-run option to dep prune

[tnozicka]

What version of Go (go version) and dep (git describe --tags) are you using?

go version go1.8.3 linux/amd64
dep - v0.3.0-22-g11758a7

What dep command did you run?

dep prune

Issue

In CI I need to be able to verify that dep prune has been run. When I was using glide, prune had option --dry-run using this you could easily tell if it was run or the contributor forgot to do so.

Could we have --dry-run flag with dep prune? (Writing out files that would have been removed.)

Thanks

[sdboyer]

hi, welcome! thanks for the issue.

sure, that seems like a reasonable request - at least, when we still have an explicit dep prune command. however, we're looking to absorb dep prune back up into dep ensure - #944. i think that would obviate the need for such a check?

[ibrasho]

I think we might need to provide the same behavior when prune is embedded in ensure, no?

[sdboyer]

@ibrasho maybe, but i'm hoping not. with prune in ensure, the pruning will either complete fully and correctly, or the command will error out and no modifications (with some very edge case exceptions) will be made to the vendor tree.

my guess is that most of what @tnozicka is trying to guard against here - and please correct me if i'm jumping to conclusions! - is developers forgetting to prune. but, as long as pruning is an automatic, unavoidable side effect of dep ensure, there's nothing to guard against.

[ibrasho]

Oh, I missed the use case. I agree that won't be needed anymore once #952 is complete and merged.

I was focused on providing enough output about which files were pruned. 😁

[tnozicka]

Hi @sdboyer,
having prune integrated might actually solve it better. What I want to achieve is to have CI pre-merge check that will make sure that the generated vendor/ directory from Gopkg.toml and .lock is what is should be because people can't really check changes inside vendor/ in reviews. And I want to avoid copying the whole source and doing diff. Mostly because it's slow and go tooling needs to be run on $GOPATH so the check would actually modify files if developer runs it locally. (or I can do magic simulating new $GOPATH)

We should even consider people editing vendor files manually.

To make that fully correct at this point you can't avoid copying because you need to first check that dep ensure followed by dep prune that generates the same result as was in vendor/ before. And because those are 2 separate commands --dry-run won't help here because if you run dep ensure --dry-run I think it will try to generate files that has been pruned. So having that integrated into ensure command would help here a lot!

Feel free to close this issue if having prune integrated in ensure is close enough because than I can use the --dry-run option that's already there and hopefully even achieve better results.

[sdboyer]

@tnozicka totally, this use case makes complete sense. and yes, you're highlighting a number of the issues that make doing this kinda thing a little tricky. i already pointed you to #121, which is a big part of this, but my current working plan is that pruning and verification won't be compatible (though i have a nascent idea developing about how we could dodge that).

given your interest in the verification problem, it'd be great for you to have a look at #950 and weigh in 😄

(closing this, per your note)