Hi everyone,
In our project we are having a dispute <https://github.com/ceph/go-ceph/pull/596> on a very similar topic as the one raised by Rodolfo Carvalho recently <https://groups.google.com/g/golang-nuts/c/R-CEvHmL1rw/m/FZxPBeW6AgAJ>, and input from this forum might help us to settle it. The situation: Our project <https://github.com/ceph/go-ceph> is a Go binding for a C API, basically one package per C library. In order to track which C API we already have a binding for, we wrote a small tool that scans both the C headers and the Go code, matches them up and outputs a report. The tool is used by developers and by the CI, but not by users of the Go bindings. The tool does not make changes to the source code of the library, it only analyses and reports on it. However, the dependencies of this tool will end up in the "require" section of the general go.mod file of the whole module. Our team has yet to come to an agreement on the best approach around go.mod use in this case. The two positions are the following: 1) The tool's dependencies should also be tracked in the general go.mod file. - Code dependencies are only expressed by "import" statements in the Go code. - At the moment the tool is very specific to this project and not usable in other projects. - go.mod is about tracking versions, and pinning the versions of the tools dependencies to the code is the right thing. - Having a separate go.mod for each internal tool makes things more complicated (as also pointed out in the FAQ <https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories> ): * Other tools like vet and gofmt must be explicitly executed for each module, "./..." doesn't work for all the code anymore. * Precautions must be taken that the local module of the tool is used, and not another version. * In theory the general go.mod file would have to include a pinning for the internal tool then (via a tools.go file). * There might be "replace" directives necessary. 2) The tool should have its own separate go.mod file. - The tool is not part of the code base and not necessary to build the Go bindings. - It feels cleaner to have a clear point of separation between the library and the tool. - It avoids unnecessary downloads in some situations. - Entries in the main go.mod could falsely advertise a dependency to users. - 3rd-party tools like packagers and security analysis tools might incorrectly interpret go.mod entries falsely as dependencies. - If the tool will get more generic, it might be easier to remove it from the repository. We are glad to hear any opinions and other recommendations on how to settle the dispute. :-) Thanks, Sven (@ansiwen) -- 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 on the web visit https://groups.google.com/d/msgid/golang-nuts/CAFwXxZT2CrjHdX7XgSTeNyzijyoB7ZVJDcbVFdtcXyeEoGAemw%40mail.gmail.com.
