Vendor pruning #120
Description
NB: keep in mind that the we see vendor/ as a temporary solution, and expect to eventually move to some newer, better version of GOPATH that largely obviates the need for it.
Currently, dep naively copies dependent repositories into vendor/ in their entirety. This may produce a vendor/ directory with a lot of unnecessary files, and many projects relying on existing community tools use some technique to prune out unneeded files.
It is unlikely that we could develop a pruning solution that would be as aggressive as every user wants, while still being safe for all other users. However, we would like to establish baseline pruning behavior that is safe for everyone, so that dep can perform it unconditionally, or with a minimum of necessary user input. If nothing else, this has performance benefits: if dep does the pruning, then it's possible for us to implement optimizations to simply avoid copying files that would later be removed.
There are a few, not fully orthogonal, classes of pruning we might consider:
- Removing nested
vendor/directories. This is required for correct builds, and dep will always do it. - Removing by build tag. Files with a particular build (or os/arch) tag could be pruned, if the user explicitly requests it in the manifest. (Note that this would not affect whether they show up in
lock.json- only whether they're pruned fromvendor.) - Removing unused packages. dep keeps track of the individual packages that are necessary to build (either
imported by code, orrequired in the manifest), and could selectively remove those that are not needed. There are sub-considerations here:- Should packages explicitly
ignored in the manifest be pruning or preserved? - Should packages/directories be preserved if they contain non-
.gofiles? What types of files?
- Should packages explicitly
- Removing unnecessary files. Similar to the previous, should certain types of files be pruned out of vendored dependencies?
There's some debate as to whether removing files may be a violation of some software licenses. Getting clarity on this question would be ideal; if we can't, then we'll likely have to make additional pruning behaviors optional in order to avoid having dep blacklisted by legal departments.
Finally, pruning is intimately linked to how we approach the problem of vendor verification (#121).
Note that the logic for writing out the dependency tree lives in gps, and is likely to remain there. This issue is to discuss what the behavior and options should be; implementation will happen over there.