On Sat, Oct 20, 2018, 11:34 AM Mark Volkmann <[email protected]> wrote:
> > On Oct 19, 2018, at 4:48 PM, Justin Israel <[email protected]> wrote: > > > > On Sat, Oct 20, 2018, 9:42 AM Mark Volkmann <[email protected]> > wrote: > >> I have a simple demo application that wants to use a package that is on >> my local file system. >> The code for the package is in /Users/Mark/foo/bar. >> This directory contains the file bar.go which contains: >> >> package bar >> import "fmt" >> func Hello() { >> fmt.Println("Hello from bar!") >> } >> >> It also contains the file go.mod which just contains: >> >> module bar >> >> The demo application in another directory imports this as "foo/bar" in >> the file main.go. >> It has a go.mod file that contains the following: >> >> module demo >> replace foo/bar => /Users/Mark/foo/bar >> >> When I enter "go run main.go" in the directory of the demo code I get >> build demo: cannot find module for path foo/bar >> >> Is there something wrong with my use of the "replace" directive? >> > > Base in this: > > https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive > > my understanding is that the path you are replacing has to first be > identified as a locatable import path, as opposed to being able to define > the location of a previously invalid path. > > > What is a “locatable import path”? > What I mean is an import path that the Go tool could locate. If you are outside a GOPATH then that would mean either a vcs pattern, something relative to the module, or something in the module cache (assumptions so far). > If your top level module is called "demo" and it contains a nested packed > "bar", > > > bar is not a nested package. It’s in a completely different directory > structure from the demo app. > So then it's even more to my point, where on its own the go tool would have no idea where to find "foo/bar" > then in the go.mod I would assume it to be called "demo/bar". If you > forget about it actually currently existing under the "demo" location on > disk, with the absence of GOPATH or a fully qualified vcs import path, how > else would the module system find "bar" if not relative to "demo"? > > > That’s what I thought the “replace” directive could do. I supplied the > full path there. > And that's the part where I am under the impression that the Go tool first wants to know where it would find "foo/bar" before it will replace it with another location. It's not a vcs and it's not relative to the module you are building. > I'm still learning about Go modules so I could be totally wrong. > >> >> None of this code is under the directory pointed to by GOPATH because I'm >> trying to use Go modules for everything in this demo. >> >> -- >> R. Mark Volkmann >> Object Computing, Inc. >> >> -- >> 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]. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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]. For more options, visit https://groups.google.com/d/optout.
