Don’t be frustrated. The design could be better imo. I am assuming much of the complexity comes from trying to optimize the build across projects that share common modules. I think there are easier ways to accomplish this. Simple mappings to version labels would be easier imo.
> On Oct 25, 2019, at 9:14 AM, Stuart Davies <sdd.dav...@gmail.com> wrote: > > > Well I can see that I am not getting this. I will carry on coding and see if > the understanding I have resolves itself. > > Thanks for all you contributions. > >> 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/a9c56752-3660-4c6b-bd9e-36887c7ff417%40googlegroups.com. -- 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/04DFDDE8-0B52-42C2-9E3E-F267DC9108FC%40ix.netcom.com.
