The glide.yaml File
The glide.yaml
file contains information about the project and the dependent packages. Here the elements of the glide.yaml
file are outlined.
package: github.com/Masterminds/glide
homepage: https://masterminds.github.io/glide
license: MIT
owners:
- name: Matt Butcher
email: technosophos@gmail.com
homepage: http://technosophos.com
- name: Matt Farina
email: matt@mattfarina.com
homepage: https://www.mattfarina.com
ignore:
- appengine
excludeDirs:
- node_modules
import:
- package: gopkg.in/yaml.v2
- package: github.com/Masterminds/vcs
version: ^1.2.0
repo: git@github.com:Masterminds/vcs
vcs: git
- package: github.com/codegangsta/cli
version: f89effe81c1ece9c5b0fda359ebd9cf65f169a51
- package: github.com/Masterminds/semver
version: ^1.0.0
testImport:
- package: github.com/arschles/assert
These elements are:
package
: The top level package is the location in theGOPATH
. This is used for things such as making sure an import isn't also importing the top level package.homepage
: To find the place where you can find details about the package or applications. For example, http://k8s.io- license: The license is either an SPDX license string or the filepath to the license. This allows automation and consumers to easily identify the license.
owners
: The owners is a list of one or more owners for the project. This can be a person or organization and is useful for things like notifying the owners of a security issue without filing a public bug.ignore
: A list of packages for Glide to ignore importing. These are package names to ignore rather than directories.excludeDirs
: A list of directories in the local codebase to exclude from scanning for dependencies.import
: A list of packages to import. Each package can include:package
: The name of the package to import and the only non-optional item. Package names follow the same patterns thego
tool does. That means:- Package names that map to a VCS remote location end in .git, .bzr, .hg, or .svn. For example,
example.com/foo/pkg.git/subpkg
. - GitHub, BitBucket, Launchpad, IBM Bluemix Services, and Go on Google Source are special cases that don't need the VCS extension.
- Package names that map to a VCS remote location end in .git, .bzr, .hg, or .svn. For example,
version
: A semantic version, semantic version range, branch, tag, or commit id to use. For more information see the versioning documentation.repo
: If the package name isn't the repo location or this is a private repository it can go here. The package will be checked out from the repo and put where the package name specifies. This allows using forks.vcs
: A VCS to use such as git, hg, bzr, or svn. This is only needed when the type cannot be detected from the name. For example, a repo ending in .git or on GitHub can be detected to be Git. For a repo on Bitbucket we can contact the API to discover the type.subpackages
: A record of packages being used within a repository. This does not include all packages within a repository but rather those being used.os
: A list of operating systems used for filtering. If set it will compare the current runtime OS to the one specified and only fetch the dependency if there is a match. If not set filtering is skipped. The names are the same used in build flags andGOOS
environment variable.arch
: A list of architectures used for filtering. If set it will compare the current runtime architecture to the one specified and only fetch the dependency if there is a match. If not set filtering is skipped. The names are the same used in build flags andGOARCH
environment variable.
testImport
: A list of packages used in tests that are not already listed inimport
. Each package has the same details as those listed under import.