Thanks a million Paul. Yes, they were resolved (for posterity, in https://github.com/golang/go/issues/28685).
On Fri, Nov 9, 2018 at 10:11 AM, Paul Jolly <p...@myitcv.io> wrote: > > I've played around with go modules in a multi module repository, and I'm > running into oddities. The main confusion is that I have this idea that any > package (and its subpackages) that has a go.mod file is a distinct, carved > out module that has no relation to its siblings and parent, even if they > happen to reside in the same repository and have their own go.mod files. > That does not seem to be the case, though. > > You are correct. Locally, there are no constraints on the > containment/nesting of modules. That is to say, a module that exists > in a sub directory of another module does not need to share the same > path prefix. > > In a remote VCS however, the containment is important if that VCS is > used as part of resolving a (custom) import path, and the go tool will > fail resolution if it not correct. > > > Questions: > > > > If pkg_a depends on pkg_b, I expect the go.mod in pkg_a to contain > "require github.com/jadekler/module-testing/pkg_b". This does not happen > when I `go mod init && go mod tidy`. Is that WAI? Why? > > If pkg_c depends on the parent module, I expect the go.mod in pkg_c to > contain "require github.com/jadekler/module-testing". This does not > happen when I `go mod init && go mod tidy`. Is that WAI? Why? > > I think these questions are answered in the GitHub issue you raised? > > Please say if not. > > Thanks, > > > Paul > -- 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.