The module https://github.com/confluentinc/confluent-kafka-go takes advantage of a custom build tag to change its behavior. (Specifically, the "dynamic" build tag forces it to use a dynamic shared library -lrdkafka instead of a built-in one; this is needed sometimes because the built-in one does not support GSSAPI/Kerberos, while the dynamic one might [and on Linux distros, generally does].)
Suppose I am writing my own package foo which uses confluent-kafka-go under the hood to implement functionality, and I require the "dynamic" behavior from confluent-kafka-go. My package must then in turn tell its users that they must build their application with the "dynamic" build tag. This in turn propagates arbitrarily far; as well, it is easy for it to become stale (suppose Confluent changes the behavior of their module to no longer use this build tag-then all these transitive users will still have a "dynamic" build tag perhaps annoyingly hanging around for a long time). Notice that the "dynamic" build tag goes together with linking with -lrdkafka, but that can be specified once, in the code close to the confluent-kafka-go package, rather than in an unbounded set of transitive reverse dependencies. Relatedly, there is nothing to prevent some unrelated package from also changing its behavior based on the "dynamic" build tag, and applications in general may want the altered behavior from confluent-kafka-go but not from some unrelated package-which may even be obscure or entirely unknown. I think there are several solutions to this difficulty; one might be a way to say in the go.mod file that a direct dependency should be built with a particular build tag, so that the application of the tag can be applied only to a portion of the build and not the whole. (This still leaves the possibility that a module might be used by two separate parts of a build, one with the tag and one without; this is fundamentally no different than a version conflict, but it might have some implications for other parts of the build system I haven't considered.) I think it's obvious that it would be better for Confluent not to have built their tooling this way, but here we are. Any use of a non-standard custom build tag in a generally imported module has this problem, so I think it's important to solve for the Go ecosystem; if the feature really is "don't use this feature" then arguably the feature should be abandoned. If it's to be kept as a feature, then there should be some way to use it safely. Thomas -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/89da7b2ac0a7420983c1890a711ac942%40deshaw.com.
