[go] Use dep instead of glide to reduce the size of vendor

[gaocegege]

Please see #541 (comment)

We met the same problem during the development of v1alpha2. And we choose to copy the code from k8s into our code base.

I think maybe we should migrate from glide to dep and use dep prune to remove useless packages.

[jlewi]

I don't have an opinion about glide vs. dep but lets try to get agreement and be consistent across Kubeflow projects.

Can you send an email to the mailing list asking folks to chime in on this issue?

Is Kubernetes using one of these options?

[gaocegege]

I think the vendor tool is not the gap since glide and dep are all easy to use. We do not need any additional work on it. Thus I think dep and glide all works for me.

I migrate from glide to dep because we are using some code in k8s.io/kubernetes and k8s code base is too large. We do not expect to put k8s code in our vendor. Now we just copy the code that we used manually into our code, but it is not the right way, I think.

Kubernetes uses godeps because of historical reasons, I think.

[gaocegege]

Maybe we could use @kubeflow to ask all members for their opinions.

It does not work. I will send an email for this issue 😃

[jlewi]

You're reasoning seems sound to me. It would be good to get buy in from the primary folks working on go-related projects as part of Kubeflow.

/cc @YujiOshima for katib
/cc @wbuchwalter For TFJobs UI
/cc @balajismaniam

[gaocegege]

Katib is using dep from the beginning 😊ཽ

[balajismaniam]

There is on-going work to migrate kubernetes/kubernetes to dep as well: kubernetes/kubernetes#57795. I think it is a good idea to standardize dep management across all kubeflow org projects.

PS: KVC uses dep.