go mod support for new operators

[estroz]

Description of the change: add go mod support by default for new operator projects with the option of using dep by setting --dep-manager=dep. print-deps will print dependencies of whichever dependency manager type is being used.

Motivation for the change: see #992.

[lilic]

General comments about this. From my experience with go modules you cannot have the project in a $GOPATH, so with this change, we would need to move away from that. We rely heavily on the $GOPATH in all the scripts and docs, but also here

operator-sdk/internal/util/projutil/project_util.go

Lines 89 to 90 in c81f98c

	func CheckAndGetProjectGoPkg() string {
	gopath := MustSetGopath(MustGetGopath())

So I would think about how to first migrage out of needing to be in $GOPATH and also focus on go module support.

[nicknezis]

@lilic Perhaps CheckAndGetProjectGoPkg() can be replaced (or somehow amended) with a function that pulls the package name from go.mod (perhaps alternative logic if go.mod exists?)

[davidovich]

This might be interesting: from the Go modules Wiki:

The full fix is to move programs that load packages off of go/build and onto golang.org/x/tools/go/packages, which understands how to locate packages in a module-aware manner. This will likely eventually become go/packages.

https://godoc.org/golang.org/x/tools/go/packages

[ghost]

Hi @estroz ,

Just a notice, according to the Go WiKi - Modules

go mod vendor resets the main module's vendor directory to include all packages needed to build and test all of the module's packages based on the state of the go.mod files and Go source code.

go mod vendor doesn't vendor unused packages or files, and I think you may have to integrate the code generation package for operator-sdk generate as well.

Thanks for your great work to make this happening!

[estroz]

This PR is on the backburner for now, but I'll be getting back on it soon.

@lilic I agree we should eliminate GOPATH requirements first then tackle modules.
@davidovich interesting, do you know how far off that feature is?
@jeffreystoke we'll use the tools.go file to get generators working. Seem my comment.

[davidovich]

@davidovich interesting, do you know how far off that feature is?

I'm not sure I understand the question, do you mean supported by the go team? (Yes) When it is available? (Now) Or it's API stability? (It is stated as stable as of December 1st 2018).

[davidovich]

@lilic

From my experience with go modules you cannot have the project in a $GOPATH,

They can, if the GO111MODULE=on environment variable is set. This env var can take three values auto, on and off. auto activates go modules when NOT in GOPATH, and deactivates them when on GOPATH. on obviously forces go modules independently of where the code is located. See the relevant entry in the go Modules wiki.

[davidovich]

I have come accross additional info: https://godoc.org/github.com/rogpeppe/go-internal/modfile can be used to parse a modfile (which this PR implements additionnally). According to golang/go#30147 (which suggests to use the rogpeppe modfile fork) and golang/go#28101 the modfile should eventually graduate outside of internal.

[lilic]

@estroz FYI there is an upstream PR to add go.mod to kubernetes, that might be of some help here -> kubernetes/kubernetes#74877

[estroz]

Note: prow CI jobs will fail until we update the CI base image to go 1.11+

[AlexNPavel]

/retest

[joelanford]

LGTM after addressing the above comment

[hasbro17]

LGTM

[lilic]

lgtm