github.com/roscopecoltran/glide@v0.12.3/docs/glide.yaml.md (about) 1 # The glide.yaml File 2 3 The `glide.yaml` file contains information about the project and the dependent packages. Here the elements of the `glide.yaml` file are outlined. 4 5 package: github.com/Masterminds/glide 6 homepage: https://masterminds.github.io/glide 7 license: MIT 8 owners: 9 - name: Matt Butcher 10 email: technosophos@gmail.com 11 homepage: http://technosophos.com 12 - name: Matt Farina 13 email: matt@mattfarina.com 14 homepage: https://www.mattfarina.com 15 ignore: 16 - appengine 17 excludeDirs: 18 - node_modules 19 import: 20 - package: gopkg.in/yaml.v2 21 - package: github.com/Masterminds/vcs 22 version: ^1.2.0 23 repo: git@github.com:Masterminds/vcs 24 vcs: git 25 - package: github.com/codegangsta/cli 26 - package: github.com/Masterminds/semver 27 version: ^1.0.0 28 testImport: 29 - package: github.com/arschles/assert 30 31 These elements are: 32 33 - `package`: The top level package is the location in the `GOPATH`. This is used for things such as making sure an import isn't also importing the top level package. 34 - `homepage`: To find the place where you can find details about the package or applications. For example, http://k8s.io 35 - license: The license is either an [SPDX license](http://spdx.org/licenses/) string or the filepath to the license. This allows automation and consumers to easily identify the license. 36 - `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. 37 - `ignore`: A list of packages for Glide to ignore importing. These are package names to ignore rather than directories. 38 - `excludeDirs`: A list of directories in the local codebase to exclude from scanning for dependencies. 39 - `import`: A list of packages to import. Each package can include: 40 - `package`: The name of the package to import and the only non-optional item. Package names follow the same patterns the `go` tool does. That means: 41 - Package names that map to a VCS remote location end in .git, .bzr, .hg, or .svn. For example, `example.com/foo/pkg.git/subpkg`. 42 - GitHub, BitBucket, Launchpad, IBM Bluemix Services, and Go on Google Source are special cases that don't need the VCS extension. 43 - `version`: A semantic version, semantic version range, branch, tag, or commit id to use. For more information see the [versioning documentation](versions.md). 44 - `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. 45 - `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. 46 - `subpackages`: A record of packages being used within a repository. This does not include all packages within a repository but rather those being used. 47 - `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 and `GOOS` environment variable. 48 - `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 and `GOARCH` environment variable. 49 - `testImport`: A list of packages used in tests that are not already listed in `import`. Each package has the same details as those listed under import.