dep

Interactively initialize deployer in the local path (use a framework template with --template=template)

$ dep init

$ dep deploy [hostname]

$ dep rollback

$ dep ssh [hostname]

$ dep list

$ dep run "[command]"

$ dep help [command]

dep command [arguments...]
dep [options] command [arguments...]

init
    Initializes a new project for dependency management or upgrades an existing one. It attempts to infer dependencies and write initial Gopkg.toml and Gopkg.lock files.

ensure
    Ensures that the project's dependencies are in the correct state. This command fetches missing dependencies, updates existing ones (if explicitly requested), or verifies the current state against the lock file.

status
    Reports the current status of the project's dependencies, indicating whether they are up-to-date according to the lock file or if there are discrepancies.

check
    Performs various checks on the project's dependency graph, identifying common problems or inconsistencies that might lead to build failures.

prune
    Removes unused or unnecessary packages from the vendor/ directory, helping to keep the project's dependency footprint minimal.

version
    Displays the version information for the dep tool itself.

-v
    Enables verbose output, providing more detailed information about dep's operations. This flag can be used with most subcommands.

-dry-run
    Performs a simulated run of the command without making any actual changes. Useful for testing dependency resolution or updates before committing changes.

dep was the official experiment for Go's dependency management, designed to manage external dependencies for Go projects. It aimed to provide reproducible builds by tracking exact dependency versions. When initialized in a project, dep creates two configuration files: Gopkg.toml (manifest, defining direct dependencies) and Gopkg.lock (lock file, recording exact versions of all dependencies, direct and transitive). It also populates a vendor/ directory with copies of the dependencies.

Commands like dep init would initialize a project, and dep ensure would fetch or update dependencies according to the manifest and lock files. It addressed common challenges like the 'GOPATH' model's limitations and the need for consistent dependency graphs across different development environments. While it gained significant adoption and laid crucial groundwork, dep has been officially superseded by Go Modules, which are now integrated directly into the Go toolchain, making dep largely obsolete for new Go development.

dep has been officially superseded by Go Modules (introduced in Go 1.11, default in Go 1.14) and is no longer actively developed. For new Go projects, Go Modules are the recommended and standard approach for dependency management.

dep relies on two primary configuration files: Gopkg.toml (the manifest, defining direct dependencies and constraints) and Gopkg.lock (the lock file, recording the exact versions of all direct and transitive dependencies to ensure reproducible builds). These files are typically committed to version control.

By default, dep places copies of all resolved dependencies into a vendor/ directory within your project. The Go toolchain is designed to look for packages in this directory first, ensuring that your project builds with its specific, vendored dependencies rather than relying on system-wide or GOPATH installations.

dep was developed by the Go team and community, launched in 2017, as an experimental, officially supported tool to solve the long-standing challenges of dependency management within the Go ecosystem. It sought to provide a consistent and reproducible way to manage external packages, addressing issues with the traditional GOPATH model. Its design principles and much of its functionality directly influenced the development of Go Modules, which later became the built-in and official dependency management solution for Go. Consequently, active development on dep ceased, as its objectives were absorbed into the core Go toolchain.

go mod(1), go get(1)