Publié · en amélioration
Guide Go · 4/6
Ce chapitre n'est disponible qu'en anglais pour le moment.
Go splits code into packages and groups packages into versioned modules. This chapter covers go.mod and go.sum, visibility, dependencies, go install, and vendoring.
A module is a collection of packages that are released and versioned together. Its definition is the go.mod file at the module root, which records the module path, the Go language version the module targets, and the other modules it depends on.
module example.com/shop
go 1.xx // filled in by go mod init from your installed toolchain
require (
github.com/google/uuid v1.6.0
golang.org/x/sync v0.7.0 // indirect
)The // indirect marker means your code does not import that module directly; something you depend on needs it. Treat the version numbers above as placeholders, since the tooling fills in real ones. Alongside go.mod sits go.sum, which stores cryptographic checksums of every module version you have downloaded. The go command verifies downloads against these hashes and, by default, against the public checksum database at sum.golang.org. Commit both files.
Each directory is one package, and its import path is the module path followed by the directory path. Visibility is controlled by capitalization alone: an identifier starting with an uppercase letter is exported and usable from other packages, while a lowercase one is private to its package. The rule applies uniformly to functions, types, variables, constants, struct fields, and methods.
// file: greet/greet.go
package greet
import "fmt"
// Hello is exported. Doc comments on exported names start with the name.
func Hello(name string) string {
return fmt.Sprintf("%s, %s!", prefix(), name)
}
// prefix is visible only inside package greet.
func prefix() string { return "Hello" }
type Config struct {
Lang string // exported field
debug bool // unexported field
}// file: main.go
package main
import (
"fmt"
"example.com/shop/greet"
)
func main() {
fmt.Println(greet.Hello("gopher"))
// greet.prefix() would not compile: it is unexported
}Name packages with a short, lowercase word, and remember that callers always see the package name in front: greet.Hello reads well, while greet.GreetHello stutters. Import cycles, where package A imports B and B imports A, are rejected by the compiler. For packages that should only be shared within your own module, use the internal directory introduced in the first chapter.
To use a third-party package, import it in your code and run go get or go mod tidy. tidy adds whatever your code imports and drops modules that nothing uses anymore, so it is a good habit to run it before committing.
# Add a dependency, or upgrade it to the newest release
go get github.com/google/uuid@latest
# Pin a specific version (downgrading works the same way)
go get github.com/google/uuid@v1.6.0
# Make go.mod and go.sum match the imports in your code
go mod tidy
# Inspect the dependency graph and available upgrades
go list -m all
go list -m -u all
# Remove a dependency
go get github.com/google/uuid@noneModules follow semantic versioning. Starting at major version 2, the major version becomes part of the import path, as in example.com/lib/v2, so incompatible majors are treated as entirely separate packages. When several dependencies require different versions of the same module, Go uses minimal version selection: it picks the highest version that anyone explicitly requires, never something newer. Nothing upgrades behind your back.
go install builds a package and places the binary in GOBIN, or in GOPATH/bin when GOBIN is unset. Adding a version suffix installs a tool in isolation, without touching the go.mod of whatever directory you happen to be in.
# Install a tool globally, independent of the current module
go install golang.org/x/tools/cmd/goimports@latest
# Install a main package from the module you are working on
go install ./cmd/server
# See where binaries end up
go env GOBIN GOPATHSometimes you need to change a library and the application that uses it together, before the library is published. Two tools help. A replace directive in go.mod swaps a module for a local directory. A workspace, created with go work, groups several modules so they build together without editing any go.mod at all.
# replace: recorded in go.mod
go mod edit -replace example.com/lib=../lib
# workspace: creates go.work (usually kept out of version control)
go work init . ../libgo mod vendor copies the source of every dependency needed for the build into a vendor directory at the module root. That helps when builds must run offline or dependency code must be reviewed in-repo. When a vendor directory exists and the module's go version is recent enough, go build uses it automatically.
go mod vendor # writes vendor/ and vendor/modules.txt
go build -mod=vendor # use vendor explicitly
go build -mod=mod # ignore vendor and use the module cacheAfter changing dependencies, rerun go mod vendor to keep the directory in sync. Most projects never need vendoring; the module cache plus a module proxy (GOPROXY) is enough. For private repositories, list their paths in GOPRIVATE so the go command fetches them directly and skips the public proxy and checksum database.
go.mod records the module path and requirements, go.sum records checksums, and both are committed.internal narrows visibility further.go get module@version to add or change dependencies and go mod tidy to clean up.go install path@version installs tools without touching your module.go mod vendor copies dependencies into the repository; reach for it only when you need it.
0 commentaire
Se connecter · Connectez-vous pour laisser un commentaire.
Soyez le premier à commenter.