switch from go dep tool to rancher/trash

[ilackarms]

This PR moves us away from using dep and Gopkg.toml for dependency management in favor of rancher/trash. Changes

• Remove Gopkg.{toml,lock}
• Create vendor.conf needed by rancher
• Re-generate vendor folder using trash; ~400 vendored files removed

[ilackarms]

@enoodle @pweil- please review

[simon3z]

Nice! 🎉

[simon3z]

@enoodle can you review/approve?

[simon3z]

@ilackarms what is this needed for? is it downloading the missing dependencies? Looking at skopeo I couldn't find anything similar. When are they running it?

[ilackarms]

@simon3z come to think of it, we don't actually need this here since we are committing the vendor folder. As long as we make sure to keep vendor and vendor.conf updated in each commit, this line is not needed.

[simon3z]

@ilackarms great, then I think we should remove this.

[ilackarms]

It's removed

[sdboyer]

hi! dep maintainer here. i'm not trying to throw a wrench in you process, but i was hoping you could tell me what problem you've encountered with dep that's motivating you to move to trash? i scanned through the other issues in the repo, but nothing jumped out at me.

again, i'm really not trying to argue about whether this is the right choice. i'm just trying to understand if there's something crucial dep is missing. learning about such things is how we improve!

[ilackarms]

@sdboyer we were experiencing a much larger vendor directory using dep; trash removed a lot more unnecessary files from vendor/

[sdboyer]

@ilackarms ah yeah, gotcha 🖖 . is that including after running dep prune? (re: that, note also golang/dep#944)

[simon3z]

Hi @sdboyer we'd like to keep using dep if possible but even after pruning the amount of vendored files is much higher compared to trash. I'd have to say that I haven't investigated why is that (maybe you have some details on this). Any suggestion on how to achieve the same result of this PR with dep? (IIUC ~500 files removed from vendor)

[sdboyer]

@simon3z i don't know offhand what trash's algorithm removes from vendor, unfortunately, so i can't say for sure. the obvious candidates would be *_test.go files and non-go files, as those are two things our current pruning logic doesn't do.

this is the kind of thing you could probably write a reasonably simple script to do. alternatively, one of our contributors has also set up their gitignore to do the work for them: golang/dep#120 (comment)

[ilackarms]

@sdboyer i can run a quick comparison of dep + gitignore and trash, i'll post the results here

[ilackarms]

against current version of master:

	committed files in vendor
just dep	1033
dep + .gitignore	674
trash	367

using git diff I found a list of files that dep adds to vendor, which trash does not:

git diff trash-deps trashcomparison  --name-only --diff-filter=A | wc -l 
384

list of the files here

[sdboyer]

huh. interesting! I'll have to dig in a little more, but it seems like the only way that can be the diff, but your code still compiles under trash, is if dep is mistaken about what code you need to compile. that would be a first, so... interesting indeed!

…

On August 4, 2017 12:05:53 PM EDT, Scott Weiss ***@***.***> wrote: against current version of `master`: | | committed files in `vendor` | | - | :------: | | just dep | 1033 | | dep + .gitignore | 674 | | trash | 367 | using `git diff` I found a list of files that `dep` adds to `vendor`, which `trash` does not: ``` git diff trash-deps trashcomparison --name-only --diff-filter=A | wc -l 384 ``` list of the files [here](https://pastebin.com/jevGWjgD) -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #68 (comment)

[sdboyer]

also to be clear, that's not "just dep" as in "dep ensure" but rather "dep ensure + dep prune," right?

…

On August 4, 2017 12:05:53 PM EDT, Scott Weiss ***@***.***> wrote: against current version of `master`: | | committed files in `vendor` | | - | :------: | | just dep | 1033 | | dep + .gitignore | 674 | | trash | 367 | using `git diff` I found a list of files that `dep` adds to `vendor`, which `trash` does not: ``` git diff trash-deps trashcomparison --name-only --diff-filter=A | wc -l 384 ``` list of the files [here](https://pastebin.com/jevGWjgD) -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #68 (comment)

[ilackarms]

yes, ran prune after ensure

[sdboyer]

ahh, so, i think i see where the big gap is coming from: trash appears to be ignoring your test files with the // +build integrationtest tag. that renders those tests uncompilable. and, given that this is your depgraph:

yaml and x/sys are likely excluded in their entirety by trash. when i remove that build tag so that trash sees ginkgo & gomega, the gap narrows considerably.

[enoodle]

Unless we can get the same level of pruning from dep I think we should switch. We can always change back when dep can improve our dependency management.

[simon3z]

yaml and x/sys are likely excluded in their entirety by trash. when i remove that build tag so that trash sees ginkgo & gomega, the gap narrows considerably.

@sdboyer is that something we can do ourselves / configure, or does it require code-changes in dep?

[sdboyer]

@simon3z there are two ways i can think of to cause ginkgo and gomega to be ignored:

1. add github.com/onsi/gomega and github.com/onsi/ginkgo to the ignored list in Gopkg.toml
2. moving pkg/inspector/{image-inspector_ginkgo_test.go,inspector_test_suite.go} into a subdirectory that Go normally treats as hidden, e.g. pkg/inspector/_inspector_tests/

unfortunately, these are both a bit crude. but we don't yet support any kind of first-class operations relating to build tags - golang/dep#291.