✨ Go modules support

[DirectXMan12]

This should be fine, as long as minimal version selection holds and you
don't call go get -u on other direct dependencies.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DirectXMan12

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [DirectXMan12]

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

[rajathagasthya]

Do we want to use replace to pin specific versions of k8s deps? k/k uses replace to pin all deps, btw.

[mengqiy]

IIUC k/k uses replace to make the staging directory work.
Unlike k/k, controller-runtime always uses a published version of k8s deps.

[rajathagasthya]

Using it for staging is part of the reason I think. They use it to pin specific versions for all dependencies. Anyway, just wanted to make sure if we want to force specific k8s versions for a given c-r release or just let minimum version selection do its thing.

[tamalsaha]

I have been playing with Go mod. It seemed to me that until k8s.io supports go mod, you have to pin using replace to pick up the correct version. So, to set dependency on k8s.io 1.14.x we are using replace.

[DirectXMan12]

replace only works on the highest-level repository, so when people consume this repo, replace won't help them.

Also, these should be kubernetes-1.14.x -- if you say "k8s.io/api kubernetes-1.14.x", go mod tidy will convert it to a version-ish thing like this, but it still should be equivalent afaict (check the date on the commit -- it should match the corresponding version from Gopkg.toml)

[rajathagasthya]

Yep, go mod tidy will convert to a "pseudo version". Also, your point about downstream consumers of this library makes sense. Thanks for clarifying.

[mengqiy]

Quoting the help text: "The -json flag prints the final go.mod file in JSON format instead of writing it back to go.mod."
What is the purpose of this? Just printing?

[rajathagasthya]

I think it's just a handy way to check if modules is enabled for the repo, given the next line grabs exit code.

[DirectXMan12]

yep, exactly! I'll add a comment.

[DirectXMan12]

(note that we're using the command's return code immediately below :-) )

[mengqiy]

you don't call go get -u on other direct dependencies.

why this is a problem when using go modules?

[rajathagasthya]

@mengqiy I think that's because Go mod authors recommend not to use go get -u when upgrading direct dependencies.

From https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies:

A common mistake is thinking go get -u foo solely gets the latest version of foo. In actuality, the -u in go get -u foo or go get -u foo@latest means to also get the latest versions for all of the direct and indirect dependencies of foo. A common starting point when upgrading foo is instead to do go get foo or go get foo@latest without a -u (and after things are working, consider go get -u=patch foo, go get -u=patch, go get -u foo, or go get -u).

[mengqiy]

/lgtm