Remove glide and switch it to dep

[abhinavdahiya]

Glide will continue to be supported for some time but is considered to be in a state of support rather than active feature development.

From https://github.com/Masterminds/glide#golang-dep

• For root vendor directory

$ rm -rf tests
$ dep init
// edit Gopkg.toml to add.
// [prune]
//   non-go = true
//   go-tests = true
//   unused-packages = true
$ dep ensure
$ git checkout tests

• For vendor in tests/smoke

$ dep init
// edit Gopkg.toml to add.
// [prune]
//   non-go = true
//   go-tests = true
//   unused-packages = true
$ dep ensure

[abhinavdahiya]

dep keeps tests/smoke/vendor/k8s.io/kubernetes/Godeps/LICENSES that adds around 80k lines :P @crawford

[wking]

While I like the vendor/ updates you have in this PR, note that dep also has:

The Go toolchain, as of 1.11, has (experimentally) adopted an approach that sharply diverges from dep. As a result, we are continuing development of dep, but gearing work primarily towards the development of an alternative prototype for versioning behavior in the toolchain.

So we may want to stick with Glide until we can bump to Go 1.11 here (which we may be able to do already? openshift/release#1365).

[abhinavdahiya]

@wking
dep has better semantics around constraints and overrides.

Also there is not a reason to believe that we can vendor kubernetes libraries with experimental go mod in go1.11. kubernetes/kubernetes#63607
I don't think go mod are going to be default until https://github.com/golang/go/milestone/65 late Jan 2019.

[wking]

dep has better semantics around constraints and overrides.

Yeah, I'm not arguing Glide vs. dep long-term. I'm just not sure it's worth spending time on dep if we are going to switch to modules in the next few months. But...

Also there is not a reason to believe that we can vendor kubernetes libraries with experimental go mod in go1.11. kubernetes/kubernetes#63607

This issues seems to be about Kubernetes supporting modules cleanly. Which would be awesome. But in the meantime, I expect we can pin to specific commits. For example, see this in my very-WIP go-modules branch from my initial poking around back in August.

I don't think go mod are going to be default until https://github.com/golang/go/milestone/65 late Jan 2019.

No, but the Go folks have committed to forward compat.

So I don't have enough experience with the modules approach to know if it will work out or not. But I'm not yet convinced it's not workable ;).

[crawford]

I see the following when I run dep ensure:

# Gopkg.lock is out of sync with Gopkg.toml and project imports:
k8s.io/apimachinery/pkg/apis/meta/v1/unstructured: imported or required, but missing from Gopkg.lock's input-imports
k8s.io/apimachinery/pkg/util/errors: imported or required, but missing from Gopkg.lock's input-imports
k8s.io/client-go/kubernetes: imported or required, but missing from Gopkg.lock's input-imports
k8s.io/client-go/pkg/api/v1: imported or required, but missing from Gopkg.lock's input-imports
k8s.io/client-go/tools/clientcmd: imported or required, but missing from Gopkg.lock's input-imports
k8s.io/kubernetes/pkg/kubectl/cmd/util: imported or required, but missing from Gopkg.lock's input-imports
k8s.io/kubernetes/pkg/kubectl/resource: imported or required, but missing from Gopkg.lock's input-imports

[crawford]

I'm in favor of switch to dep, even if we end up switching to go modules relatively soon.

[crawford]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abhinavdahiya, crawford

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [abhinavdahiya,crawford]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[abhinavdahiya]

/retest