原文作者:Jekyll
A module is a collection of related go packages. Modules are the unit of source code interchange and versionning.
go get
.vgo
is being merged and refined as go mod
(experimental).This article refers to recurrent expressions. Let’s clarify them:
go.mod
.go
command is run.A module is a tree of Go source files to which is added a file named go.mod. It contains the module import name, and the declaration of dependency requirements, exclusions and replacements. Its content would look like this:
1module my/thing
2
3require (
4 one/thing v1.3.2
5 other/thing v2.5.0 // indirect
6 ...
7)
8
9exclude (
10 bad/thing v0.7.3
11)
12
13replace (
14 src/thing 1.0.2 => dst/thing v1.1.0
15)
Note that a dependency not directly imported in the module’s source code by an import statement is indentified as indirect in the file.
A module can contain other modules, in which case their content is excluded from the parent module.
Alongside go.mod, a file named go.sum
may be present. This file retains cryptographic checksums of module dependencies, if any. It is used to verify that cached dependencies meet module requirements.
A module root can reside anywhere on the filesystem, whatever is the current GOPATH.
Dependencies are downloaded and stored in GOPATH/src/mod
. A direct consequence is that the use of a vendor directory is now obsolete.
What does this new structure looks like? Suppose we are working on a module that depends on github.com/me/lib at version 1.0.0. For such a case, in GOPATH/src/mod we would find:
What we can observe is:
@version
.In Go 1.11beta2, the environment variable GO111MODULE
controls whether module support is enabled or disabled. It accepts three values: on
, off
, auto
(default).
If set to “on”, module support is enabled whatever path we are in.
If set to “off”, it is permanently disabled.
If unset or set to “auto”, module support is enabled outside of GOPATH only if the current directory is a module root or one of its subdirectories.
Go modules are integrated with Go tools, for instance upon invocation of commands such as go build
, go install
, go run
, go test
appropriate actions will fire up like populating the cache, creating or updating go.mod and go.sum etc.
You should never have to run these commands on your own since they are invoked by other commands, but for the sake of completeness, let’s mention that go mod -fmt
is the equivalent of go fmt
for go.mod and go.sum files and that go mod -fix
do some smart things in order to keep go.mod clean, like:
To create go.mod:
1go mod -init
You may have to pass the command an import path with -module <path>
if the module root lives outside a VCS.
For the sake of backward compatibility and in order to ease the transition process, module creation has support for popular dependency management tools like dep
, glide
, glock
,godep
and so on.
In order to clean up unused dependencies or to fetch new ones, use the sync option:
1go mod -sync
Two possibilities: either edit go.mod by hand or use the CLI. The latter comes with the following commands:
1# require a new dependency
2go mod -require one/thing@version
3
4# drop a requirement
5go mod -droprequire one/thing
6
7# exclude a dependency
8go mod -exclude bad/thing@version
9
10# drop an exclusion
11go mod -dropexclude bad/thing@version
12
13# replace a dependency
14go mod -replace src/thing@version=dst/thing@version
15
16# drop a replacement
17go mod -dropreplace src/thing@version
To print the graph of module dependencies:
1go mod -graph
If for backward compatibility reasons you need to ship your application with vendoring, you can generate the vendor directory from go.mod thanks to:
1go mod -vendor
Don’t hesistate to refer to go help mod
and go help modules
for further details about Go module support!
版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。
Golang语言社区
ID:Golangweb