dep ensure is not as aggressive as dep prune

[bhcleek]

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

Tested with

dep:
version : v0.4.1
build date : 2018-01-27
git hash : 37d9ea0
go version : go1.9.3
go compiler : gc
platform : darwin/amd64

And with v0.4.1-145-gd5c4d780

What dep command did you run?

With a [prune] configuration:

[prune]
  go-tests = true
  non-go = true
  unused-packages = true

dep ensure; git status; dep prune; git status

What did you expect to see?

I expected dep prune to not remove anything.

What did you see instead?

dep prune removed a lot.

Additional details:
One simple way to duplicate this is to clone https://github.com/bhcleek/digitalocean-cloud-controller-manager/commit/c34a5cd7b5ff9e6d4959172c2518d715257286df, add

[prune]
  go-tests = true
  non-go = true
  unused-packages = true

, and then run dep ensure -update github.com/spf13/pflag, check the output of git status, run dep prune and check the output of git status; the output of the first git status is more substantial than the second.

edit: changed repo URL and commit sha to avoid introducing unrelated concerns.

[mattayes]

Hi @bhcleek, dep prune is deprecated and should be avoided. What kind(s) of files are removed by dep prune that aren't removed by dep ensure with the settings provided? Also, should the title of this issue be "dep ensure is not as aggressive as dep prune"?

[bhcleek]

Thanks, @mattayes. I realize that dep prune is deprecated, but I was surprised by the difference in behavior.

I can provide specific differences later if my description and instructions above are insufficient.

[bhcleek]

I crafted a script to show the differences between the two approaches to pruning:

#!/bin/sh

export GOPATH=$(mktemp -d)

mkdir -p $GOPATH/src/github.com/digitalocean
cd $GOPATH/src/github.com/digitalocean
git clone -b dep-1820 [email protected]:bhcleek/digitalocean-cloud-controller-manager
cd digitalocean-cloud-controller-manager

dep ensure -update github.com/spf13/pflag
dep prune
git status > explicit-prune.status

git reset --hard
git clean -f -d -x -e explicit-prune.status

printf '[prune]\n  unused-packages = true\n' > Gopkg.toml
dep ensure -update github.com/spf13/pflag
git status > implicit-prune.status

diff -u implicit-prune.status explicit-prune.status

[mattayes]

@bhcleek Do I have to check out your specific branch for this to happen or can I use github.com/digitalocean/digitalocean-cloud-controller-manager? What's the difference between them?

[bhcleek]

I cherry-picked one commit into the branch in my fork, but otherwise it's the same. https://github.com/bhcleek/digitalocean-cloud-controller-manager/commit/c34a5cd7b5ff9e6d4959172c2518d715257286df was originally done in https://github.com/digitalocean/digitalocean-cloud-controller-manager/commit/e1e66d82169c135f481ab833bd2bcadc8d1204fb, but it came after the dep ensure -update github.com/spf13/pflag in github.com/digitalocean/digitalocean-cloud-controller-manager. I cherry-picked it just to avoid a potential red herring for root cause so that this issue can be used to focus on the pruning behavior.

[sdboyer]

Yeah, this is just one of those things - the whole conceptual basis for pruning changed substantially with the introduction of separate pruning options. The goal was never really 1:1 parity, though we did try to be reasonably close.

i'm happy to discuss making some of the new pruning behaviors more aggressive in more targeted issues, but because this issue is sorta implicitly about the non-goal of achieving parity with the old dep prune, i'm gonna close it.