https://github.com/golang/go/wiki/Modules#can-i-work-entirely-outside-of-vcs-on-my-local-filesystem
For a simple parent/child module relationship this seems to work, since the 'replace' work-around is in the parent go.mod. But when the childA depends on childB, then the 'replace' directive in childA's go.mod is ignored, and the build fails. According to the above information this is working as designed. Since there is no error feedback that the 'replace' directive has been ignored, I eventually stumbled over a couple of similar reported issues. Which is how I also found the information that sub-module 'replace' directives are being ignored. https://github.com/golang/go/issues/29376 https://github.com/golang/go/issues/31345 Since I'm just learning Go I would like to understand the approach better. I come from a Maven background for dependency management. Here it is a common pattern to have a parent/child module design. Each child module can specify it's own dependencies. And in complex projects two different sub-modules or sub-sub-modules may even have requirements on different versions of the same library (Logging I'm looking at you!). So this question is also applicable when running under VCS. ie that Go sub-modules may want to specify a specific version of a library that they depend upon using the replace directive. Anyway I am left with the impression that this parent/child module pattern might be considered non idiomatic in the Go world? ie Go is targeting a 1-to-1 mapping of VCS project to Module. Is that fair to say? -- 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. For more options, visit https://groups.google.com/d/optout.
