You should be able to use a `replace` directive to replace the full path "github.com/Michael-F-Ellis/skeleton/internal/common" or similar. If you take that approach, the skeleton module itself *must not* contain that package, or else the `import` statements that refer to that package would be ambiguous.
You can think of that path as specifying “the identity of the hook package” rather than “the location at which the source code for the hook package can be found”. From that perspective, the path "gitlab.com/SomeOneElse/someproject/internal/common" wouldn't make sense: it may be a completely different package with its own identity and meaning. On Wednesday, March 3, 2021 at 6:54:28 PM UTC-5 [email protected] wrote: > On Wednesday, March 3, 2021 at 6:11:38 PM UTC-5 [email protected] > wrote: > >> On Thu, Mar 4, 2021 at 12:02 AM Michael Ellis <[email protected]> >> wrote: >> >>> What's the right way to handle this use case? >>> >> >> I think the right way to handle it is to modify the file. In the final >> code, the import path should unambiguously point to where the code can be >> found - regardless of whether it was using your skeleton to get started. >> You might write a tool to do that modification automatically, if you want >> to simplify things. >> > > Thanks even though it's not the answer I was hoping for. Seems to me that > since the Go Authors have accorded special status to directories named > "internal" the module mechanism should recognize references to it and not > require a globally unique path string. > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5cbe16a0-465e-43dd-9611-76b82fc45617n%40googlegroups.com.
