Should GoCenter serve modules with bad requirements?

[elioengcomp]

This discussion was started by #42

At this moment, GoCenter have a strong opinion about which modules are available and will not serve modules with a bad requirements. It validates that by performing a basic go get and checking for success.

However, some Go Modules, specially in the k8s ecosystem, use redirect statements to fix bad requirements or to pin to specific versions of dependencies. Since this redirect statements are ignored by Go Modules when consuming a module as a dependency, GoCenter gets failures during its validation processes and consider them not ready to be consumed as dependencies, hiding them from the users and showing them in a error state in the UI.

Most of those modules know they cannot be consumed as dependencies via the regular user behavior. To promote their usage, they provide custom bootstrap logic so users can start new projects using them as dependencies. One example is the operator-sdk new command that creates a new module with github.com/operator-framework/operator-sdk as a dependency and all the replace statements required by it and its transient dependencies so the new module can be built properly.

This custom bootstrap tools cannot be used with GoCenter since its strong opinion will cause those modules not to be available in the first place.

Since the k8s ecosystem contains some of the most import Go projects, to promote usage of GoCenter with those projects, should GoCenter still serve modules that fail its validation process? Should the results of the validation only be considered additional metadata about how healthy the requirements composition of a modules is instead?

[bcmills]

Also consider modules that are themselves intended to be used in a replace directive: they will have a module directive containing the path for the module to be replaced, rather than the path from which they were fetched, so go get should reject them.

However, such modules are not invalid for their intended use-case.

[Groxx]

To copy and paste (and slightly rewrite) my stance from the gophers slack, with hefty caveats of "I'm not really familiar with k8s code or how people use it" + "I'm more familiar with the theory side of mvs/modules, less implementation" + "please let me know if I'm off-base, I'd very much prefer to learn":

---

Is the issue that people are trying to use k8s code in their system, but k8s doesn’t define rational versions of its dependencies for them (v0.0.0 everywhere), so users can't download it? And so GoCenter needs to either allow returning bad systems like this everywhere, or not be compatible with k8s (currently)? [1]

If that’s accurate, tbh I kinda feel like this is k8s' problem, and they shouldn’t be allowed to inflict pain on the whole ecosystem. They’re effectively not using Go modules, except for internal purposes. To support their repos being imported by 3rd parties, either k8s needs to change, or Go modules as a whole need to change to allow transitive == constraints or something (which seems pretty unlikely to happen to me). [2]

If users of their code have enough issues, either they’ll stop using it or complain loudly enough to get it changed. Or k8s will set pointless-but-valid min versions so module systems are happy, and add a readme that says "include these replace directives or it’ll break" (which looks like what they do themselves: https://github.com/operator-framework/operator-sdk-samples/blob/0d98e8c156d7db9d83e9073f7f73371af882ee12/go/memcached-operator/go.mod ). [3]

---

[1] I'm intentionally excluding "make an exception for k8s" since it's likely harder than either extreme, and exceptions tend to become rules so it's nearly equivalent to the first option.

[2] If their only intent is to simplify internal development of their own repos, this is 100% acceptable and reasonable and I fully support them doing it. Having a go.mod does not mean you desire to be imported by others.

[3] Requiring additional steps beyond what a build system can do for you is IMO unavoidable in some situations (codegen, system dependencies, etc) and that's fine... but when you start baking its behaviors into automated meta-build-systems, you start forcing everyone to deal with incompatibilities between competing meta-build-systems. It's the same kind of issue as godep/Glide/Dep had to deal with in the absence of any official system (and k8s didn't work well with them either IIRC). Either conform to the widely-used official build system, or force people to do something different by hand and deal with the backlash.

[peterbourgon]

The replace directive in an included module doesn't make it invalid, it's simply ignored in the final module graph. I don't think its presence alone should render a module invalid from the point of view of tooling.

[elioengcomp]

GoCenter opinion on modules requirements has been removed and modules with bad requirements can now be resolved from GoCenter.