Skip to content
This repository has been archived by the owner on May 6, 2022. It is now read-only.

Migrate from glide to dep for dependency management #1670

Merged
merged 7 commits into from
Jan 25, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,6 @@ bin/**
coverage.html
.idea/
.DS_Store
.glide
.scBuildImage
.init
.generate*
Expand All @@ -21,3 +20,7 @@ contrib/build/*/tmp/*
.kube
.var
.vscode
vendor/github.com/petar/GoLLRB/doc/*
contrib/examples/consumer/Gopkg.lock
contrib/examples/consumer
contrib/examples/vendor/*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

besides gollrb, are these to just avoid dealing with contrib? dep automagically finds them or something?

Copy link
Contributor Author

@carolynvs carolynvs Jan 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

contrib/examples/consumer is something that I added to test a downstream consumer using dep to vendor the Service Catalog client library. make test-dep runs dep to vendor our generated clientset, and ensures that the app can compile. I added those ignore lines so that after running that target, a bunch of generated test files don't show up when someone runs git status. 😀

That test-dep target helps us sanity check that the constraints in our Gopkg.toml aren't missing anything with respect to downstream consumers. Otherwise, we wouldn't find out for example that we need to be pinning to a particular revision, or avoiding a bug with a semver range until someone reported it to us.

When we use dep internally when working on service catalog, dep takes into account our Gopkg.lock where all of the dependencies are locked to an exact revision. When someone vendors us using dep, only Gopkg.toml is used. That's why I was asking a bunch of questions in the sig meeting on Monday about why in our glide.yaml so many projects were pinned to an exact revision. I wanted to figure out how much we had to manually manage in the Gopkg.toml and what we could "get away with" letting dep deal with in the Gopkg.lock file.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh neat!

2 changes: 1 addition & 1 deletion .travis.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ services:
- docker
cache:
directories:
- .glide
- $GOPATH/pkg/dep
script:
- make verify build build-integration build-e2e test images svcat
deploy:
Expand Down
Loading