Go Language Modularization: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 106: Line 106:
Go programs are constructed by linking together [[Go_Packages#Overview|packages]]. There must be a [[Go_Packages#The_main_Package|<code>main</code> package]], which contains the <code>main()</code>, to trigger the linker.
Go programs are constructed by linking together [[Go_Packages#Overview|packages]]. There must be a [[Go_Packages#The_main_Package|<code>main</code> package]], which contains the <code>main()</code>, to trigger the linker.
=Project=
=Project=
See [[Go_Packages#Vendoring|Vendoring]].
=Repository=
=Repository=
A Go repository typically contains only one [[Go Modules|module]], located in the root of the repository.
A Go repository typically contains only one [[Go Modules|module]], located in the root of the repository.


=Package and Encapsulation=
=Package and Encapsulation=

Revision as of 17:56, 8 September 2023

Internal

Overview

Go modularization builds upon the concepts of package and module. Packages provide a namespace for their members, and they are a way to encapsulate code, hide implementation details and only expose features, such as variables, functions or type definitions that are meant to be publicly consumed. Packages can be published as part of modules. Modules have been introduced in Go 1.11.

Packages

Packages

Standard Library

Go comes with a set of over 100 "built-in" packages, which are available as part of the locally installed Go development environment.

Standard library package documentation is available online here:

https://pkg.go.dev/std

The standard library is a good source of code examples, comments and style guidance.

Standard library packages:

archive atomic bytes container database encoding errors
flag fmt io ioutil encoding/json hash log
math net os path reflect regexp runtime
slices sort strings strconv sync text/template time
unicode

pkg.go.dev

The place to look for published third-party packages is

https://pkg.go.dev

Modules

Modules

Module-Aware or GOPATH Mode

https://go.dev/ref/mod#mod-commands

The compiler must locate packages on the local file system every time it handles an import statement.

The go tool has two modes of resolving package dependencies: module-aware mode or GOPATH mode.

In module-aware mode, the go commands use go.mod files to find versioned dependencies and typically load packages out of the module cache, downloading modules if they are missing. As of Go 1.16, the module-aware mode is enabled by default, regardless of whether go.mod is present or not. The behavior can be controlled with the GO111MODULE environment variable.

In GOPATH mode, go commands use the value of the GOPATH environment variable and vendor directories to resolve packages.

Also see:

GoLand Module-Aware or GOPATH Mode

Workspace

https://go.dev/blog/get-familiar-with-workspaces

The workspace is a concept introduced in Go 1.18. A workspace allows organizing the code for a project that has several modules which share a common list of dependencies. The workspace maintains metadata, especially dependency metadata, in a file called go.work. The dependencies declared in this file can span modules and anything declared in go.work will override dependencies in the modules's go.mod. The packages and modules maintained in a workspace are managed with the go tool.

A workspace may contain multiple projects.

The standard workspace layout is:

. ← GOPATH should point to this directory, it contains src, pkg and bin
│
├─ src 
│   ├─ a 
│   │  └─ b
│   │     └─color  # "color" package directory, with the "a/b/color" import path
│   │        ├─ colors.go 
│   │        ├─ aux.go 
│   │        └─ ... 
│   │
│   ├─ weight  # "weight" package directory, with the "weight" import path
│   │   ├─ weights.go 
│   │   ├─ aux.go 
│   │   └─ ... 
│   │
│   ├─ novaordis.com
│   │   └─ tools
│   │       └─ hammer # "hammer" package directory, with the "novaordis.com/tools/hammer" import path
│   │           └─ ... 
│   │
│   └─ github.com
│       └─ blue-org
│           └─ tools
│               └─ wrench # "wrench" package directory, with the "github.com/blue-org/tools/wrench" import path
│                   ├─  .git
│                   └─ ... 
│ 
├─ pkg 
│   └─ darwin_amd64 
│       ├─ weights.go 
│       ├─ a/b/color.a 
│       ├─ novaordis.com/tools/hammer.a
│       └─ github.com/bue-org/tools/wrench.a
└─ bin

Content

src

The src subdirectory holds source code. Each package resides in a directory whose name relative to ${GOPATH}/src represents the package's import path.

The src subdirectory may contain multiple version-control repository workareas.

pkg

The build tool stores compiled packages in the pkg directory, under ${GOOS}_${GOARCH} subdirectories.

bin

The bin directory is where the executables are stored.

Relationship between Workspace and GOPATH

GOPATH should point to the root of the workspace, the directory that contains src, pkg and bin. Further research is required.

Program

Go programs are constructed by linking together packages. There must be a main package, which contains the main(), to trigger the linker.

Project

See Vendoring.

Repository

A Go repository typically contains only one module, located in the root of the repository.

Package and Encapsulation