OK I think I have cracked it! I needed a *go.mod* file in the root path. module github.com/mygit/webserver
go 1.13 This basically means that the *go.mod* file in examples can find a *go.mod* file at ../ replace github.com/mygit/webserver => ../ The clue was in the error message from earlier. The only thing I missed was that when you do: go mod init <name> The <name> must be the module name *'github.com/mygit/webserver'* not the go file name. While in example the <name> is the application (main) name --> *webserver.go*. I can see the logic for this but I do not think the distinction is clear in the documentation. *I think it's: * If your going to code something that will be imported use the github. *com/x/y* for the name. If its an application that is importing then use the application name. Please correct me if I am wrong. Thanks every one for you contributions. I am back to coding :-) On Monday, 23 September 2019 16:25:30 UTC+1, Stuart Davies wrote: > > Hi. > > > I have been using GO for about a year and I love the language and ideas > behind the language. I am also a Java developer for many years, I switched > from Delphi to Java 1, the new and exciting language from Sun (a bit like > GO is now from Google). > > > > In Java we have Maven and Gradle (sorry Ant) to make dependency hell more > manageable so I understand the need for modules in Go. I have just > installed GO 1.13 and thought I would convert an existing 'pet' project to > use modules. It did NOT go well! > > > > What I need is a dummies guide to the GO module so I can build good, > reliable, standards compliant GO applications. > > > > I needs to explain the new terminology in the context of a module, like > 'vendor'. Not just a one liner, I NEED to understand! > > > > I know how to use Google but the quality of the articles I have read on > this subject is minimal and just brushes the surface. > > > > If I have a reasonably large and complex (pet) project with local packages > in it. I like to split my project in to small units with 'namespaces' to > keep it manageable. These are NOT reusable components until I decide they > qualify and publish on Github. > > - Why MUST I import them as if they are from github and then 'replace' > them, and if I don’t 'MUST' then you have failed to explain this feature > to > me! > - My local packages are part of my application. They are, I agree > still 'dependencies' but they are not 'DEPENDENCIES' that I need (or even > want) to import from a repository. They are part of my project. > - What if I do not want to host my project on a GIT repo (Shock > horror!). > - Why do all imports start with github.com. Is that a requirement, > what is the rational for this. > - How does a 'import' resolve its 'reference'. > - Should I add the go.mod and go.sum files to my repository or should > the developer who cloned my project have to do a go mod init (bummer!). > > *Can someone please explain, properly!* > > We must have Modules and Repositories (like Maven Central) for the > 'Enterprise' to manage dependencies but what about 'keep it simple' for the > rest of us (and for that matter more mature enterprise developers like > myself). > > > > Please help me get this understood. This is the sort of thing that can > raise a language above the rest and I would really like that to happen. Go > is brilliant… > > > > Regards > > > > Stuart > -- 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/94ac77f6-2b88-4c05-a8e1-6bf70252468d%40googlegroups.com.
