On Tuesday, January 28, 2020 at 12:34:04 AM UTC+1, R Srinivasan wrote: > > Oops. That was messed up. > > I have so far not migrated towards the new go modules. I am beginning the > process. Looking for ideas. > > I split my applications into independent packages each in its own > directory. > > the structure might look like: > > top/src > /pkg1 > /pkg2 > > the imports are based on relative paths - eg: > import ( > "../pkg1" > ) >
That's really the wrong way to go. If top is equal to $GOPATH, then there is no need to use relative imports. If you do `import "pkg1", the import path will be automatically resolved to top/src/pkg1. The difference with the new modules systems is that import paths will no longer be resolved to a local filesystem path using $GOPATH. > > Questions: > - there is just 1 go.mod at the top level right? > - go.mod only specifies what the external packages are. > eg.google.olang.org/package > > I'm a bit confused to what do you mean as top level. Assuming pkg1 and pkg2 are different projects, maybe inside a vcs repository, then each project will have it's own go.mod file. If the projects are inside GOPATH (yes, GOPATH is still useful with modules), run `go mod init` inside the project root directory, and it will automatically create a new go.mod file. Also, with modules *all* packages not inside a module are external. This means that the module path should specify a remove resource, like "github.com/user/project". If the module path is like "pkg1", go will report an error since it does not know how to get it. The alternative is to use the replace directive. You can check the official documentation or the wiki. Manlio Perillo -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/abee61a0-003c-4183-a413-4f1fb0e02cd3%40googlegroups.com.
