Go module learning notes

Posted by nishmgopla on Sat, 11 May 2019 01:33:20 +0200

1. Create a mudule and publish it

1.1 $GOPATH/src directory structure

1.2 Environment Variables

Need to add environment variable: GO111MODULE=on;

This variable has three optional values:

  1. On (GoEnable this feature anywhere),
  2. off (disable this feature),
  3. auto (default, enabled elsewhere with GOPATH disabled)

Otherwise console will output the next step

go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'

1.3 Enter the hello directory

Execute command: go mod init github.com/Aruforce/hello

console output: go: create new go.mod: module github.com/Aruforce/hello

Add a file go.mod:

module github.com/Aruforce/hello
go 1.12 //go version

1.4 Add code

hello.go:

package hello
func Hello() string {
    return quote.Hello();
}

hello_test.go

package hello
import "testing"
func TestHello(t *testing.T) {
    want := "Hello, world."
    if got := Hello(); got != want {
        t.Errorf("Hello() = %q, want %q", got, want)
    }
}

1.5 Release

1.5.1 Release

git add * //Add Files
git commit -m 'first commit' //Notes
git remote add origin https://github.com/Aruforce/hello.git //Add remote warehouse
git push -u origin master //Push

1.5.2 tag and Push

git tag v1.0.0 //Note that this format is prescribed by Go and is v(major). (minor).(patch)
git push --tags //Push tag

git checkout -b v1 //Check out v1 branch to prevent BUG s from being modified
git push -u origin v1 //Pushing empty content to branch v1 means creating a new branch remotely

2. Use the above module in a new project

2.1 Directory Structure

2.2 Code File

mod.go:

package modtest
import (
  "fmt"
  "github.com/Aruforce/hello"
)
func Mod() string{
  return hello.Hello();
}

mod_test.go:

package modtest
import "testing"
func TestMod(t *testing.T) {
  want := "Hello, world."
    if got := Mod(); got != want {
        t.Errorf("Mod() = %q, want %q", got, want)
    }
}

2.3 Initialization Project

go mod init github.com/Aruforce/hello

2.4 Download Dependent Code

Command:

go get // download code, etc. in the $GOPATH/pkg/mod directory

console:

go: finding github.com/Aruforce/hello v1.0.0
go: downloading github.com/Aruforce/hello v1.0.0
go: extracting github.com/Aruforce/hello v1.0.0

go.mod:

module github.com/Aruforce/modtest
go 1.12
require (
  github.com/Aruforce/hello v1.0.0 
  // Because there is no information about the specified version and so on in the code, the code we refer to has published v1.0.0,
  //go get pulls out the code for the maximum version number in the v1.x.x tag list;
  //If tag go is not published, it will fake version number v0.0.0-time-commit code
  //This code is (commit hashcode of the last master when the code is first pulled out),
  //Then pull the substitution codes, except that go does not actively update these codes when it is built unless we actively request updates such as go get -u
  // When you see this file, you can actually modify the version number manually, without using any go get-u patch...
)

go.sum:

github.com/Aruforce/hello v1.0.0 h1:CNC4ZenBDAah3mib7fwBztu9ZHVYkjNzMAKMhKlLreQ= //Project Version
github.com/Aruforce/hello v1.0.0/go.mod h1:SPJXz6EybRNTFDg7RAoekS+HdftZtWbdXaa8W+Mr8YM= //The module itself goes.mod file MD5 value as a security check

2.5 hello version update causes modtest to be updated as well

2.5.1 minor or pacth updates

There's only one thing we need to do

go get -u 
//perhaps
go get -u =patch //This will only upgrade one patch if there is v1.0.0 v1.0.1 v1.0.2 This will only download v1.0.1 code after execution.
//perhaps
go get github.com/Aruforce/hello@v1.0.2 //This is to download the specified version code

2.5.2 major update

It looks like Major's updates depend on different things, but I don't think it's useless, because to keep a code compatible, the safest way to do this is not to modify the old API, which is the open and close principle: APIs only allow additions, not modifications;

2.5.2.1 Requires a single code base at the same time, in case of version conflict

See the following code

package modtest
import (
  "fmt"
  "github.com/Aruforce/hello" // v1 version
  hv2 "github.com/Aruforce/hello/v2"
  //v2 is equivalent to a completely new dependency on go. Whether the alias given by golang or hello for the path of this pattern is a conflict on the original version's name requires a special declaration, that is, a conflict resolution
  // When you go get and so on, you download the code for v2.x.x
)
func Mod() string{
  fmt.Println(hv2.Hello());
  return hello.Hello();
}

2.5.2.2 Direct major upgrade scenario

See the following code:

package modtest
import (
  "fmt"
  "github.com/Aruforce/hello/v2"//v2 is a completely new dependency on go, and the alias given by golang to the path of this pattern is hello, which makes it impossible to modify your code at all
  //When go get, etc., the code for v2.x.x maximum version number is downloaded
)
func Mod() string{
  fmt.Println(hv2.Hello());
  return hello.Hello();
}

2.5.2.3 and circumstances not related to us

See the following code

package modtest
import (
  "fmt"
  "github.com/Aruforce/hello" // v1 version
  //In this case, minor patch updates will not affect as long as we don't go get -u manually
  //Large version updates, even go get-u will not update to large version, unless life is shown
  //The rest is to use the new version you specified
)
func Mod() string{
  return hello.Hello();
}

3. Remove unwanted dependencies

Since the go build does not actively remove unwanted dependencies, we will manually remove them by executing the following commands

go mod tidy

4. No concept of a local warehouse was found for go module

Maybe not. How big is the text document... and people don't have walls either.

5. Hopefully the go module will settle down as a fixed feature...vendor seems to be abandoned...

6. I feel worse than maven for the following reasons:

  1. maven was the first to develop the test deployment process and rely on coordinated standards, while maven and jar central warehouse are just standard practices; go mod feels like a small shell script that can't even be practiced;
  2. go has too many built-in conventions to modify and is mixed with the compiler
  3. You haven't seen a plug-in for resource file processing so far (this may not be necessary (... you don't have to follow the environment to configure the file)
  4. The document is too crude

Topics: github git Maven REST