Revert "Simplified and updated go.mod"

[porridge]

Reverts #1325 because it re-introduces the issue fixed in #1244
cc @armandgrillet @nfnt

[nfnt]

If this is only about the code-generator, let's only bump this to v0.18.0-alpha, not revert the bump of the other deps to v0.16.6. Bumping the other deps fixes issues as well.

[nfnt]

How does the issue in #1244 manifest? It isn't detected by the CI, which makes it hard to determine which dependencies can be bumped. How about adding a replace directive in go.mod instead? This would make it clear that this specific version is intended to be used. Not sure if comments can be used in go.mod, but having an additional comment here would be great as well.

[armandgrillet]

Sorry for reintroducing a bug, I was unaware of the mentioned issue. I've just tried bumping k8s.io/code-generator on the master branch to v0.18.0-alpha.1 (then v0.18.0-alpha.2) but it then introduces other issues, will have to keep working on it.

[porridge]

How does the issue in #1244 manifest?

Code generation script barfs when running with GOPATH unset or GOBIN set to something else than $GOPATH/bin, IIRC.

It isn't detected by the CI, which makes it hard to determine which dependencies can be bumped.

Right. I don't think we invoke code generation in the CI runs at all, do we?

How about adding a replace directive in go.mod instead? This would make it clear that this specific version is intended to be used.

When reading the documentation for go.mod it did not seem to me that this is what replace is to be used for? Also, I'm not sure that:

require k8s.io/code-generator v0.16.6
replace k8s.io/code-generator v0.16.6 => k8s.io/code-generator v0.18.whatever

would qualify as making the intent clear :-)

Not sure if comments can be used in go.mod, but having an additional comment here would be great as well.

I think it allows comments. However I don't think that would scale. Even if we commented that a particular version of a dependency is necessary for some reason X, we would have no idea whether that ceases to be true if X is no longer a valid reason (as there can be other reasons).

This whole file is a delicate mesh of subtleties and it's not possible to document what would fail in case one of these lines are changed. The only assertion we can make is that "it worked like this for whoever touched it last, possibly only after lots of sweat and tears". I think that increasing test coverage to also invoke the less often used tooling is the only way to go...

[armandgrillet]

@porridge Would backporting kubernetes/code-generator@6b257a9 to https://github.com/kubernetes/code-generator/tree/release-1.16 and then using it in KUDO make sense?

[porridge]

@porridge Would backporting kubernetes/code-generator@6b257a9 to https://github.com/kubernetes/code-generator/tree/release-1.16 and then using it in KUDO make sense?

In theory yes, but in practice it took over a month to get that change merged, and this time we'd need to wait for another k8s point release after that.
But perhaps we could replace k8s.io/code-generator v0.16.6 => github.com/kudobuilder/code-generator v0.16.6-withpatch
WDYT about creating a temporary fork under kudobuilder @gerred ?

[jimmidyson]

If code-generator is only used as a tool (not runtime dependency) then I would consider making tools a go module in it's own right in a subdirectory (/tools/) in this repo. Sorry if I've missed context!

[gerred]

@jimmidyson you're not wrong. Check out tools.go - that's how and why we're getting these into go.mod, based on the recommendation here: https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module

It's a little clunky, but it's at least recognizable as a pattern in a few projects now. @porridge I'm OK with that patch. Do we have a path forward to not rely on that long term and get these dependencies up to date? Or at least, a diff of things that prevent us from using the most up to date code generator now? If so, we can in parallel start working on stamping out those issues in the KUDO codebase proper.

[jimmidyson]

@gerred My point is that by adding all the tools dependencies into your module's go mod you're adding dependencies which aren't actually source dependencies, but purely build dependencies. By moving the tools dependencies into their own submodule in <REPO_ROOT>/tools then you separate out build time dependencies from source dependencies, which has saved me time on other projects when updating conflicting dependencies, as well as benefitting downstream projects by limiting transitive dependencies, again to save time fighting conflicting dependencies.

[porridge]

Superseded by #1359