Using Go Modules

I&#x27;ve been using Go modules, and I really like them. It&#x27;s obvious they really paid a lot of attention to backwards compatibility. Being able to vendor using mod is really awesome, as well as see all your transitive dependancies automatically. It&#x27;s very goish to focus on minimizing your dependancies and actually think about what you&#x27;re pulling in. I&#x27;m not yet sure how I feel about the v2+ stuff. Having a separate module for breaking changes is something I think I&#x27;ll have to try more to form an opinion on, but I dislike the idea of embedding the version in the name instead of using the mod file.<p>I do think it&#x27;s kind of odd that it decides to put packages in GOPATH, but disallows you from coexisting go mod projects in GOPATH. I organize all my code for all my languages using the go repo as dir. I&#x27;ve had to maintain a separate tree for go mod which is not ideal.<p>After using Go dep and mod, I felt that dep was the super straightforward and obvious way to do it. It&#x27;s how I would have done it. Go mod is much more Goish, it&#x27;s opinionated and based on a philosophy that fits with the language. It Gives me hope that if they do add generics they will make them uniquely Go as well.

Making sure I understand this: I’m some independent developer working in many languages. I like every project I work on to be inside ~&#x2F;work&#x2F; within a subdir I name based on the project.<p>I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~&#x2F;work&#x2F;go&#x2F;src&#x2F;github.com&#x2F;joshklein&#x2F;project&#x2F;cmd&#x2F;hello_world.go, but now I can have ~&#x2F;work&#x2F;go_hello&#x2F;src&#x2F;main.go. Right?<p>I understand this isn’t the main point, but frankly it’s the thing I care the most about.

I&#x27;m not an active golang user, but something which gives me pause here is the insistence on a strict 3-number semver.<p>For a commercial entity shipping software which may include upstream components, it&#x27;s important to have options for maintaining (and versioning) in-house forks of upstream components. This becomes a problem when you fork v1.2.3 from upstream and want to internally release your fixes, but now your internal 1.2.4 and upstream&#x27;s 1.2.4 both have the same number but diverge in content.<p>I like the Debian solution to this, which permits freeform textual suffixes, so that in the hypothetical scenario above, you can release v1.2.3bigco1, v1.2.3bigco2, with the final number indicating the version of the patchset being applied onto the upstream release; then it&#x27;s also clear what to do when you rebase your fork because you&#x27;ve maintained the integrity of the upstream version.

<i>&quot;the go command automatically looks up the module containing that package&quot;</i><p>Looks up where? GOPATH? The tree below the current file? The current directory? What&#x27;s the &quot;current module&quot;, anyway? Where is that stored?<p><i>&quot;go: downloading rsc.io&#x2F;sampler v1.3.0&quot;</i><p>Downloading from where? Github? From what repository? The page for &quot;go get&quot; now talks about &quot;module-aware&quot; mode, but doesn&#x27;t make it clear how that works.<p>This is the usual headache with dependency systems. There&#x27;s some specific directory layout required, and you have to know what it is. This article needs to be more explicit about that. Otherwise you end up depending on lore and monkey copying.

I&#x27;ve been using Go modules for a bit and I really like it. I can easily set up local dependencies using the `replace` keyword as well. For instance, all of the apps in `cmd` which need access to common packages are their own modules, and then I just add:<p><pre><code> replace pkg =&gt; ..&#x2F;..&#x2F;pkg </code></pre> And I can refer to everything inside of `pkg` (`pkg` is its own module as well).

The meat:<p>&gt; go mod init creates a new module, initializing the go.mod file that describes it.<p>&gt; go build, go test, and other package-building commands add new dependencies to go.mod as needed.<p>&gt; go list -m all prints the current module’s dependencies.<p>&gt; go get changes the required version of a dependency (or adds a new dependency).<p>&gt; go mod tidy removes unused dependencies.<p>And you can use some sugar to declare exact versions you want.

The main thing that annoys me about Go modules is that it broke so much tooling. I still can&#x27;t get GoCode to work properly, and there are 4 or 5 different forks of the repo all trying to add module support, its a mess.

Google API&#x27;s latest semantic version is behind the doc site (godoc.org&#x2F;google.golang.org&#x2F;api). Is this standard practice in Go?<p>I was coincidentally converting my Go project to use Go modules yesterday. I depended on a Google API which was originally retrieved via &#x27;Go get&#x27;, corresponded to docs and worked fine as this pulled from HEAD. `go mod` did not work out of the box, as it required the latest semantic version (v.0.2.0) of my this Google API import. This version, however, is behind documentation and broke my code.<p>I understand I can require a specific commit in the go.mod file, but the strings for specific commit seem cryptic. Where can I look up the version hash that matches the doc site?

I&#x27;ve returned to university recently. We&#x27;re learning Make in one of my classes at the moment (&quot;learning&quot; Make seems so weird to me). When going over dependency graphs I couldn&#x27;t stop thinking of how awesome `go mod tidy` is.

I haven&#x27;t been using Go modules, to the point where I only have a vague notion of what they do.<p>I haven&#x27;t felt the need for them.<p>At what point do they become necessary? Which pain-points should I be on the lookout for?

Be warned that if you like all the tooling VSCode provides for Go then that is still not available if you are using go modules. They are working on it and there are some rough betas out there for some limited functionality but simple things like renaming variables etc, are still not available.<p>Realize this is a tooling issue and not necessarily a language one, but do feel like they should be mentioning this. It makes working with modules pretty painful. (we are doing it but man do I miss simple refactors &#x2F; usages etc..)

All I wanted was a way to safely and easily cleanup my $GOPATH. I don&#x27;t have a lot disk space and $GOPATH takes up most of it.<p>This thing apparently doesn&#x27;t solve my problem. `go mod tidy` simply removes a dependency from a module, but that dependency is still cached in a big arcane directory at $GOPATH&#x2F;src&#x2F;mod. Why?<p>I think we all should be using something like Nix for dependency management that solves all problems, but that is so hard to setup!

question: what happens if you wanna organize your software in modules? so for example, a main module (package main) and a secondary module (core). Do you init both as separate modules? and then you use the second as dependency on the first one? do they have to be actually published somewhere to be accessible in this way?

There are at least two bugs in this tutorial:<p>- There&#x27;s a duplicated section starting with: &quot;Note that our module now depends on both rsc.io&#x2F;quote and rsc.io&#x2F;quote&#x2F;v3:&quot;<p>- In the example of upgrading a major version, Hello was renamed to HelloV3, but the caller isn&#x27;t renamed. It should be &quot;quoteV3.HelloV3&quot;.

In the &quot;Upgrading dependencies&quot; section when they use &quot;go get&quot;, will the command be local to that module? I am used to &quot;go get&quot; working with the idea of a $GOPATH. I almost wish they introduced another sub-command to update a dependency.

not ready yet for production, most of the cli tools such as errcheck dont work. <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;24661" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;24661</a><p>other than that it works like a charm, here&#x27;s a tutorial i wrote: <a href="https:&#x2F;&#x2F;getstream.io&#x2F;blog&#x2F;go-1-11-rocket-tutorial&#x2F;" rel="nofollow">https:&#x2F;&#x2F;getstream.io&#x2F;blog&#x2F;go-1-11-rocket-tutorial&#x2F;</a>

How do you reference local go modules that are under development? The equivalent in node is `npm link`.

Every mainstream programming language that came out in the last 20 years has already solved this. Java, Javascript, Ruby, Python, Rust, you name it.<p>I am baffled to why Go has not figured this out and are presenting recent developments as some kind of breakthroughs - they are not.<p>To me, and I&#x27;m not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental&#x2F;keep an eye on bucket. It does some things really, really well but it&#x27;s far from the panacea most developers that use it think it is.