I've beat my head into the module wall a bit as well, and while I don't understand some of the design decisions, I've done my best to answer your questions inline.
On Mon, Sep 23, 2019 at 1:42 PM Stuart Davies <sdd.dav...@gmail.com> 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 GO module so I can build good, reliable, > standards compliant GO applications. > > > > It needs to explain the new terminology in the context of a module, For > example '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! > > Go now has two distinct ways of finding dependencies. Module mode (export GO111MODULE=on) and the non-module mode (export GO111MODULE=off). Each mode resolves dependencies differently. In Module mode, all imports are assumed to be paths to git version control systems, such as github, and that's how they're always interpreted, that was a design choice. If you have a local directory with source code that's not on a git server with a matching name, that's when you use the 'replace' directive to point it at the local directory, otherwise, Go will try to contact that server. Github doesn't have to be in the name, for example, you could make a /tmp/stuart/mymodule "namespace", import it as "fake.host/stuart/mymodule", and you'd have to specify a "replace fake.host/stuart/mymodule => /tmp/stuart/mymodule" directive. With modules turned off, things make a little bit more sense. Imports are just strings, so "import foo/bar/baz" would try to import $GOPATH/src/foo/bar/baz, and AFAIK, there aren't any restrictions on naming these things. > > - 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. > > The easiest way to deal with this is to refactor your dependencies to be subdirectories within your main project/module. If they're subdirectories, and share one global go.mod file, you're not dependent on github or anything, and this module can have any name. If you ever intend to publish it for public consumption, though, you'd need to give it a github name. > > - What if I do not want to host my project on a GIT repo (Shock > horror!). > > Use non-module mode, where it's up to you to manage the contents of $GOPATH/src, or put everything in the same module, since the name doesn't matter when you're operating within a module's directory tree. > > - Why do all imports start with github.com. Is that a requirement, > what is the rational for this. > > They must start with a hostname resolvable to a git server, that's all. For example, gopkg.in shows up a lot as well. I have my own internal gerrit server, and I use that hostname. This behavior is documented here: https://golang.org/cmd/go/#hdr-Remote_import_paths It appears that several version control systems are special cased. > > - How does a 'import' resolve its 'reference'. > > In module mode, it contacts the server at your import path, with a query saying that it's Go asking the question, and it expects a code location back as an answer, it's documented here in that link above. If you "import foo.com/bar", Go issues the query "https://foo.com/bar?go-get=1";, and expects some VCS meta-info back as a response. That tells Go that we're talking to Git or Mercurial or whatever, as well as the actual path to the repository. > > - 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! > Your go.mod and go.sum should go into your repository. Together, they unambiguously specify _your_ set of dependencies. It's up to you to manage them in a way which makes your library function properly, and when others clone it, they can be assured that they're getting the same code that you got when you built it. Modules are kind of ugly, but they solve the important issue of reproducibility. In early Go, before 1.6, you had to manage your own dependencies by copying them into your GOPATH. You also ended up with versionitis, where you may need moduleX:1.0.0 but one of your dependencies only works with moduleX:0.7.5, but due to the flat nature of Go source, you were stuck with some gross refactoring. Go 1.6 introduced "vendoring", where each "package", aka, subdirectory in $GOPATH could copy its depdendencies into its own repository as a vendor directory, so in my contrived example above, you'd get: myProject/ vendor/ moduleX (copy of module X at version 1.0.0) dependency/ vendor/ moduleX (copy of module X at version 0.7.5) This was better, but still unwieldy, since you now had to manage this dependency tree mostly by yourself, and sometimes, you and a dependency needed to call a common library, and things would break if they weren't compatible versions. So, go modules allow you to specify a specific repository, project and version as a dependency, and Go itself takes care of keeping the various versions of dependencies at a compatible version level. The price you pay for this is that you lose the ability to easily use modules in local directories. > > 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). > I turn off Go modules via GO111MODULE=off for this case, and check out all my dependencies into $GOPATH/src myself. I have a GOPATH for my experiments, and a proper GOPATH from which I publish code that I'm paid to write, which is all git, all the time. > > 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… > Go modules, IMO, are a stepping stone to a better future, and much better than what we had before. It's not reached the maturity level of Gradle or maven or something. I imagine that as people run into the shortcomings of modules, things will continue to evolve. For example, Go modules make it incredibly annoying to have some modules public in github, while others are private in your own, login-protected VCS system. > 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/b79c351d-5657-4ee7-bfd9-c3294d8bbf95%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/b79c351d-5657-4ee7-bfd9-c3294d8bbf95%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CA%2Bv29LvdMFW7GR5%2BHOsDqpi2ZNYTtyf5cMZFhxgXPfmp16h9xA%40mail.gmail.com.
