Go conventions: Use Go modules for applications

[dennwc]

Update code convention to use Go modules for dependency management of applications. The change omits vendor intentionally. A separate discussion will be opened for this.

Also, highlight points for libraries/applications and update supported Go versions.

The reasoning is that we don't need an external tool like dep anymore to build applications. Our version policy for applications is to support one latest release of Go, which is 1.12, and it supports modules natively.

As noted in the epic (non-public link) most of our projects already switched to modules or are in the transition process. This change merely reflects the decision made previously and was already put into motion.

[kuba--]

Why only for applications? I would do it for libraries, as well.

[kuba--]

Are we gonna, transfer to native go imports (after supporting modules) - github, or continue using gopkg?

[dennwc]

@kuba-- I'll open separate discussions for each of those points right after this PR is merged.

[creachadair]

Are we gonna, transfer to native go imports (after supporting modules) - github, or continue using gopkg?

In my view we should use native Go imports with modules, but there's some benefit to keeping old imports working. (If we can get dependency analysis up and running we could discover whether this actually affects anyone 😄).

[kuba--]

if we introduce go modules for apps and libs, personally I would make import paths consistent across all projects. Having gopkg made sense for dep. With modules this mix looks like a legacy stuff, so maybe it's time to rethink rewriting import paths as well.

[dennwc]

@kuba-- Makes total sense, but let's discuss that separately :)

[mcuadros]

For the libraries, we should use gopkg.in, otherwise, you force to everyone to use go modules if they want versioned stuff, something that feels wrong.

Also,another important thing is the amount of work to change this, with the minumun outcome. Because you can't simply change the import path to the libraries, for example go-git

[creachadair]

For the libraries, we should use gopkg.in, otherwise, you force to everyone to use go modules if they want versioned stuff, something that feels wrong.

I think this is incorrect, in two ways: (1) Anyone can still import versioned packages without Go modules, either via the gopkg.in path or from its real import path; and (2) Our compatibility promise only covers versions of Go that support modules, so no one is left behind when we use modules.

Even if someone insists, for some reason, on not using modules to import our packages, they can still get any version they want from the base import path. They will of course have to update their import path to upgrade, but that's a choice they are making, not something we forced on them.

I do not think it makes sense for us to use gopkg.in for our own dependencies just because others want to use it for theirs. I argue we should make sure gopkg.in imports still work, but otherwise not worry about them.

That brings me to the second point:

Also,another important thing is the amount of work to change this, with the minumun outcome. Because you can't simply change the import path to the libraries, for example go-git

I'm not sure which "this" you mean. Using Go modules has not required much work—it's mostly been updating our own import paths, which we already agreed to among the leads and we have already done.

[dennwc]

@smola Friendly ping.