Commit 523c34e8 authored by Hilko Bengen's avatar Hilko Bengen

New upstream version 0.3.2


Too many changes to show.

To preserve performance only 657 of 657+ files are displayed.

enabled: true
enabled: true
enabled: true
- "**.go"
- vendor/
- internal/gps/_testdata
- cmd/dep/testdata
- testdata
- internal/gps/internal/pb
# Prevent problems comparing golden files on Windows
**/testdata/** text eol=lf
# general
* @sdboyer
# init
/cmd/dep/init* @carolynvs
/cmd/dep/gopath_scanner* @carolynvs
/cmd/dep/root_analyzer* @carolynvs
/cmd/dep/testdata/init @carolynvs
/cmd/dep/testdata/harness_tests/init @carolynvs
/internal/importers @carolynvs
/analyzer* @carolynvs
/testdata/analyzer @carolynvs
/internal/feedback @carolynvs
# ensure
/cmd/dep/ensure* @ibrasho
/cmd/dep/testdata/harness_tests/ensure** @ibrasho
# status
/cmd/dep/status* @darkowlzz
/cmd/dep/testdata/harness_tests/status** @darkowlzz
/cmd/dep/graphviz* @darkowlzz
# gps caching
/internal/gps/source_cache* @jmank88
Thanks for filing an issue! If this is a question or feature request, just delete
everything here and write out the request, providing as much context as you can.
### What version of `dep` are you using (`dep version`)?
If you installed `dep` via `go get`, report the version instead with
`cd $GOPATH/src/ && git describe --tags`
### What `dep` command did you run?
Paste the output of the commands you ran in here, making sure to pass -v for maximum context.
The output of `dep hash-inputs` may also be helpful to include.
### What did you expect to see?
### What did you see instead?
Work-in-progress PRs are welcome as a way to get early feedback - just prefix
the title with [WIP].
Add the change in the changelog (except for test changes and docs updates).
Please edit and add the change under the appropriate category (NEW
FEATURES, IMPROVEMENTS & BUG FIXES) along with the PR number.
### What does this do / why do we need it?
### What should your reviewer look out for in this PR?
### Do you need help or clarification on anything?
### Which issue(s) does this PR fix?
fixes #
fixes #
# dep project generated files to ignore
# if you want to ignore files created by your editor/tools,
# please consider a global .gitignore
# please do not open a pull request to add something created by your editor or tools
language: go
sudo: false
email: false
- stage: test
- go get -u
- npm install -g codeclimate-test-reporter
os: linux
go: 1.9.x
- go test -i ./...
- ./hack/lint.bash
- ./hack/validate-vendor.bash
- ./hack/validate-licence.bash
- ./hack/coverage.bash
- codeclimate-test-reporter < coverage.txt
# YAML alias, for settings shared across the simpler builds
- &simple-test
go: 1.8.x
stage: test
install: skip
script: go test -race $(go list ./... | grep -v vendor)
- <<: *simple-test
go: tip
- <<: *simple-test
os: osx
go: 1.9.x
# brew takes horribly long to update itself despite the above caching
# attempt; only bzr install if it's not on the $PATH
- test $(which bzr) || brew install bzr
# OSX as of El Capitan sets an exit trap that interacts poorly with how
# travis seems to spawn these shells; if set -e is set, then it can cause
# build failures. We're not doing that here, but retain the trap statement
# for future safety.
# Related:
- trap EXIT
- go test -race ./...
- go: 1.9.x
stage: deploy
install: skip
script: skip
- ./hack/build-all.bash
- provider: releases
secure: fL9GX11J3JLizEBTPZHN32wuAT91eAJsGl0kjlAdIc6Lb/9UCe1XZGgFnpQFN4qo/S+omhHBDbM6Ty1xhNy7xmjDecpQGDU8Rmap9Oll0TuxqMigG+njOuPp5VUYPofPP0PGKdxAcYg+KaFM7x0o2rK+qA046NHwo2gH1BbE+bn55TZglEajEfc8j9iX4jt96KC7zlu+WiKArLmfUtlrI8m8ZYgbYcvFmlYjeCiEqlNhvNL59ejug9Rl0PLtPbamqVXkGLafYtekgPCb4WSxBiCt8pq5Rb5svk9YcdXpiaWQhZjMPAuKN6BrmN2lw1PiXzADUG5fjvNc8eo2HY70GD2utU9cAsY8VIafhoH5n6uM1WI8MHwDfd7P1PiQA3ZGQ8CPwk4q/8HSfQU9ap7vZgSF63pTIbtlviyIG67orOJE9PWWncl9olYM946UylZu6m3hWI/rmJxOeJ1UJjym/3GNPMRfKubaGhV/TyRdM0bKX4M0cXHU6k/ESVFupGXdKRt4RpvkD4/1Km6b2OShW6PNI+ifFspnJr7obkI7dm7ubySdnNz4lMv9WWymxRpMVc8hUAhuoDvXeZJq7pSnkjBEWDxIRoTkA93CU3/Rf7MFYCJMnGSqjcxWUpIfCAk2/r4BqL9NQnqBvvVt+MYi64QaD5n7ZF3dVbr6HZ2zjSU=
- release/dep-linux-amd64
- release/dep-linux-amd64.sha256
- release/dep-darwin-amd64
- release/dep-darwin-amd64.sha256
- release/dep-windows-amd64
- release/dep-windows-amd64.sha256
skip_cleanup: true
repo: golang/dep
branch: master
tags: true
# This source code refers to The Go Authors for copyright purposes.
# The master list of authors is in the main Go distribution,
# visible at
# v0.3.2 (Unreleased)
* Add support for importing from [gvt](
and [gb](
* Wildcard ignore support. (#1156)
* Disable SourceManager lock by setting `DEPNOLOCK` environment variable.
* `dep ensure -no-vendor -dry-run` now exits with an error when changes would
have to be made to `Gopkg.lock`. This is useful for CI. (#1256)
* gps: Fix case mismatch error with multiple dependers. (#1233)
* Skip broken `vendor` symlink rather than returning an error. (#1191)
* Fix `status` shows incorrect reason for lock mismatch when ignoring packages.
* Allow `dep ensure -add` and `-update` when lock is out-of-sync. (#1225)
* gps: vcs: Dedupe git version list (#1212)
* gps: Add prune functions to gps. (#1020)
* gps: Skip broken vendor symlinks. (#1191)
* `dep ensure -add` now concurrently fetches the source and adds the projects.
* File name case check is now performed on `Gopkg.toml` and `Gopkg.lock`.
* gps: gps now supports pruning. (#1020)
* `dep ensure -update` now concurrently validates the passed project arguments.
Improving performance when updating dependencies with `-update`. (#1175)
* `dep status` now concurrently fetches repo info. Improving status performance.
* gps: Add SourceURLsForPath() to SourceManager. (#1166)
* gps: Include output in error. (#1180)
* gps: Process canonical import paths. (#1017)
* gps: Persistent cache. (#1127, #1215)
# v0.3.1
* gps: Add satisfiability check for case variants (#1079)
* Validate Project Roots in manifest (#1116)
* gps: Properly separate sources for different versions & github
* gps: Add persistent BoltDB cache (#1098)
* gps: Increase default subcommand timeout to 30s (#1087)
* Fix importer [issue]( where the
importer would drop the imported version of a project (#1100)
* Import analyzer now always uses the same name, fixing the lock mismatch
immediately after dep init issue (#1099)
* Add support for importing from [govend](
(#1040) and [LK4D4/vndr]( (#978) based projects
* gps: gps no longer assumes that every git repo has a HEAD (#1053)
* `os.Chmod` failures on Windows due to long path length has been fixed (#925)
* Add `version` command (#996)
* Drop support for building with go1.7 (#714)
* gps: Parse abbreviated git revisions (#1027)
* gps: Parallelize writing dep tree (#1021)
* `status` now shows the progress in verbose mode (#1009, #1037)
* Fix empty `Constraint` and `Version` in `status` json output (#976)
* `status` table output now shows override constraints (#918)
* gps: Display warning message every 15 seconds when lockfile is busy (#958)
* gps: Hashing directory tree and tree verification (#959)
* `ensure` now has `-vendor-only` mode to populate vendor/ without updating
Gopkg.lock (#954)
* Use fork of Masterminds/semver until
Masterminds/semver [issue#59](
is fixed upstream (#938)
* gps: Ensure packages are deducible before attempting to solve (#697)
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of
experience, nationality, personal appearance, race, religion, or sexual identity
and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, or to ban temporarily or permanently any
contributor for other behaviors that they deem inappropriate, threatening,
offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at sam (at) All complaints
will be reviewed and investigated and will result in a response that is deemed
necessary and appropriate to the circumstances. The project team is obligated to
maintain confidentiality with regard to the reporter of an incident. Further
details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 1.4, available at [][version]
# Contributing to `dep`
`dep` is an open source project.
It is the work of hundreds of contributors. We appreciate your help!
Keep an eye on the [Roadmap]( for a summary of where the project is, and where we're headed.
## Filing issues
Please check the existing issues and [FAQ](docs/ to see if your feedback has already been reported.
When [filing an issue](, make sure to answer these five questions:
1. What version of Go (`go version`) and `dep` (`git describe --tags`) are you using??
3. What `dep` command did you run?
4. What did you expect to see?
5. What did you see instead?
General questions should go to the [golang-nuts mailing list]( instead of the issue tracker.
The gophers there will answer or ask you to file an issue if you've tripped over a bug.
## Contributing code
Let us know if you are interested in working on an issue by leaving a comment
on the issue in GitHub. This helps avoid multiple people unknowingly
working on the same issue.
Please read the [Contribution Guidelines](
before sending patches.
[help wanted](
label highlights issues that are well-suited for folks to jump in on. The
[good first issue](
label further identifies issues that are particularly well-sized for newcomers.
Unless otherwise noted, the `dep` source files are distributed under
the BSD-style license found in the LICENSE file.
All submissions, including submissions by project members, require review. We
use GitHub pull requests for this purpose. Consult [GitHub Help] for more
information on using pull requests.
We check `dep`'s own `vendor` directory into git. For any PR to `dep` where you're
updating `Gopkg.toml`, make sure to run `dep ensure` and
([for now]( `dep prune` and commit all
changes to `vendor`.
[GitHub Help]:
## Contributor License Agreement
Contributions to this project must be accompanied by a Contributor License
Agreement. You (or your employer) retain the copyright to your contribution,
this simply gives us permission to use and redistribute your contributions as
part of the project. Head over to <> to see
your current agreements on file or to sign a new one.
You generally only need to submit a CLA once, so if you've already submitted one
(even if it was for a different project), you probably don't need to do it
## Maintainer's Guide
`dep` has subsystem maintainers; this guide is intended for them in performing their work as a maintainer.
### General guidelines
* _Be kind, respectful, and inclusive_. Really live [that CoC]( We've developed a reputation as one of the most welcoming and supportive project environments in the Go community, and we want to keep that up!
* The lines of responsibility between maintainership areas can be fuzzy. Get to know your fellow maintainers - it's important to work _with_ them when an issue falls in this grey area.
* Remember, the long-term goal of `dep` is to disappear into the `go` toolchain. That's going to be a challenging process, no matter what. Minimizing that eventual difficulty should be a guiding light for all your decisions today.
* Try to match the toolchain's assumptions as closely as possible ([example](, and avoid introducing new rules the toolchain would later have to incorporate.
* Every new flag or option in the metadata files is more exposed surface area that demands conversion later. Only add these with a clear design plan.
* `dep` is experimental, but increasingly only on a larger scale. Experiments need clear hypotheses and parameters for testing - nothing off-the-cuff.
* Being a maintainer doesn't mean you're always right. Admitting when you've made a mistake keeps the code flowing, the environment health, and the respect level up.
* It's fine if you need to step back from maintainership responsibilities - just, please, don't fade away! Let other maintainers know what's going on.
### Issue management
* We use [Zenhub]( to manage the queue, in addition to what we do with labels.
* You will need to install [ZenHub extension]( to your browser to show the board.
* Pipelines, and [the board]( are one thing we try to utilize:
* **New Issues Pipeline**: When someone creates a new issue, it goes here first. Keep an eye out for issues that fall into your area. Add labels to them, and if it's something we should do, put it in the `Backlog` pipeline. If you aren't sure, throw it in the `Icebox`. It helps to sort this pipeline by date.
* **Icebox Pipeline**: Issues that we aren't immediately closing but aren't really ready to be prioritized and started on. It's not a wontfix bucket, but a "not sure if we should/can fix right now" bucket.
* **Backlog Pipeline**: Issues that we know we want to tackle. You can drag/drop up and down to prioritize issues.
* Marking dependencies/blockers is also quite useful where appropriate; please do that.
* We use epics and milestones in roughly the same way (because OSS projects don't have real sprints). Epics should be duplicated as milestones; if there's a main epic issue, it should contain a checklist of the relevant issues to complete it.
* The `area:` labels correspond to maintainership areas. Apply yours to any issues or PRs that fall under your purview. It's to be expected that multiple `area:` labels may be applied to a single issue.
* The [`help-wanted`]( and [`good-first-pr`]( labels are two of our most important tools for making the project accessible to newcomers - a key goal for our community. Here's how to use them well.
* `good-first-pr` should be applied when there's a very straightforward, self-contained task that is very unlikely to have any hidden complexity. The real purpose of these is to provide a "chink in the armor", providing newcomers a lens through which to start understanding the project.
* `help-wanted` should be applied to issues where there's a clear, stated goal, there is at most one significant question that needs answering, and it looks like the implementation won't be inordinately difficult, or disruptive to other parts of the system.
* `help-wanted` should also be applied to all `good-first-pr` issues - it's duplicative, but not doing so seems unfriendly.