Vendoring dependencies for dgraph

Users
4

I don’t want to over complicate this task but IMO we must consider all the possibilities before making a decision on how do we want to vendor dependencies. As discussed here (build: use `vendor` directory for dependencies · Issue #4182 · cockroachdb/cockroach · GitHub) there are multiple solutions and things associated with them that we need to be careful about. Below are some of the options, feel free to add more to the list.

  • Option 1 - Use govendor or glide and check-in the /vendor directory with the src (if we are going with this option then we can just merge Dan’s @compton branch). But as mentioned in the #4182 issue on roachdb this will clutter the main repo codebase and anytime we upgrade dependencies or add new ones, PR merging will be a hassle.

  • Option 2 - Keep a separate repo under github.com/dgraph-io/vendor where all the dependencies are vendored (this can be created using glide or govendor) and add that as a submodule to dgraph repo. This will keep the main repo cleaner but adds an extra step of making sure that updated dependencies are checked in the right repository. cockroachdb is not going with this approach as they want to make local modifications in their dependencies and use them with existing tooling workflows. @mrjn - do you potentially see this being a scenario for dgraph?

  • Option 3 - Check in the dependency list file + the lock file to the main repo but ignore the /vendor directory. With a fresh check-out or pull one can always use glide or govendor to create or update the dependencies in the vendor directory. This is the least complicated solution but opens us up to left-pad scenario where original repos might vanish leaving us with a broken build.

One of the primary reasons I started this conversation was because of glock of installing dependencies in my GOPATH rather than using a dedicated install location (like a lot of folks I use a single GOPATH for my projects and any overwriting of dependencies is not a good experience).

Given that right now we have a limited set of dependencies, we can start with Option #3 and then decide between #1 or #2. This addresses my concern regarding installing dependencies in GOPATH but gives us freedom to choose either #1 or #2 later.

Thoughts?

1 Like