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.

Reply via email to