Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

dep ensure is not as aggressive as dep prune #1820

Closed
bhcleek opened this issue Apr 20, 2018 · 6 comments
Closed

dep ensure is not as aggressive as dep prune #1820

bhcleek opened this issue Apr 20, 2018 · 6 comments

Comments

@bhcleek
Copy link

bhcleek commented Apr 20, 2018

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 bhcleek/digitalocean-cloud-controller-manager@c34a5cd, 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
Copy link
Contributor

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 bhcleek changed the title dep ensure is not as aggressive as dep ensure dep ensure is not as aggressive as dep prune Apr 22, 2018
@bhcleek
Copy link
Author

bhcleek commented Apr 22, 2018

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
Copy link
Author

bhcleek commented Apr 26, 2018

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
Copy link
Contributor

@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
Copy link
Author

bhcleek commented Apr 26, 2018

I cherry-picked one commit into the branch in my fork, but otherwise it's the same. bhcleek/digitalocean-cloud-controller-manager@c34a5cd was originally done in digitalocean/digitalocean-cloud-controller-manager@e1e66d8, 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.

matyix added a commit to banzaicloud/pipeline that referenced this issue Apr 27, 2018
We have this [dep](golang/dep#1820) issue with non-go files while prune-ing (dep ensure actually). This triggers the page build failures we wanted to address with #452
matyix added a commit to banzaicloud/pipeline that referenced this issue Apr 27, 2018
We have this [dep](golang/dep#1820) issue with non-go files while prune-ing (dep ensure actually). This triggers the page build failures we wanted to address with #452
@sdboyer
Copy link
Member

sdboyer commented Jul 11, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants