Starting with the 2.5 develop branch, Juju core has migrated to use upstream dep as the tool to manage its dependencies. For further reading on the tool itself, see https://golang.github.io/dep/. This will replace our home grown godeps.
As a developer, if you use the existing make targets to update your dependencies when switching branches or pulling new revisions, nothing much changes in respect to your current workflow. The main difference is that the make targets have been renamed. See below for details.
One impact will be the creation of a vendor directory (which is git ignored) in the Juju source tree. This contains a flattened copy of Juju’s dependencies and may be quite large (a few hundred MB).
How to use it
There are 2 artifacts which define the dependencies and their locked revisions:
These essentially replace the godeps
dependencies.tsv file. See the dep docs for more details.
Ensure local copy of upstream dependencies are up to date
godeps -u dependencies.tsv
dep ensure -vendor-only
dep ensure command copies the frozen dependencies as specified in the lock file into the
The first time will take longer as everything is downloaded again but after that the flattened dependencies are cached locally and subsequent runs are incremental updates.
If you want to work on older 2.3 or 2.4 branches, as always you need to ensure that the dependencies are updated after switching. With this change, you now also need to remove the vendor directory if it exists. The
godeps make target has been updated to do this. Or if you prefer to run
godeps -u dependencies.tsv manually, you will also need to remove the vendor directory manually as well.
Add a new dependency
Say there’s a brand new upstream repo for which you want to create a Juju dependency. Add it like so:
dep ensure -add github.com/foo/bar
This will pull the upstream code and ensure that the toml and lock files are updated. These files need to be proposed for landed into Juju the same way that a
dependencies.tsv update would be.
Bring in an upstream dependency change
Say there has been a change committed to an upstream dependency and you want a new revision to be used by Juju. As is the case with godeps, you first need to pull this upstream dependency change to update your local copy. Then…
godeps -t ./... > dependencies.tsv
Copy the sha you want to use and edit the
Gopkg.toml file to use this sha.
This will run
dep ensure -v -no-vendor to rebuild the lock file based on
Gopkg.toml. These files need to be proposed for landed into Juju the same way that a dependencies.tsv update would be.
Work on upstream dependencies
Say you want to update some code in an upstream dependency like
The locally cloned copy of the repo will exist in the usual location under $GOPATH. The version used when building Juju is picked up from the
./vendor directory so there’s a few extra steps involved in do the work.
- Ensure you have cloned the repo locally.
go get -u github.com/juju/testing
- Make whatever changes you want to the source code in this location.
These first 2 steps are the same as what we do when using godeps.
You have two choices on how to test your changes with Juju:
- Copy the entire repo to the Juju
cp -r $GOPATH/src/github.com/juju/testing $GOPATH/src/github.com/juju/juju/vendor/github.com/juju/testing
You will also need to prevent
make build or
make install from overwriting your changes to the vendor directory. Either set the environment variable:
supply it as an argument to make:
make install JUJU_SKIP_DEP=true
- Commit and push your changes to your fork of
juju/testingand note the commit sha. Edit the
Gopkg.tomlfile and run
Now you can build and test your changes on the juju repo
After you are happy with the changes, you can put up a pull request etc and merge your changes upstream.
After landing the change upstream, use the steps outlined in the previous section to update the toml and lock files and propose the change to the Juju repo.
git commit ...
git push ...