goop drags in dependencies of a parent directory

[tummychow]

Imagine I depend on package X. Package X is a subfolder of some larger repository Y. I put package X into my goopfile and specify the revision of Y that I want. goop install will bring in package X, but it also drags in the dependencies of all the stuff in Y.

Real world use case, consider this Goopfile:

github.com/influxdb/influxdb/client #632dba81dcb9769cbc7005a83d52f28fc5c6c7cc

InfluxDB is a time series database written in Go... in other words, it is a big project. The official Go client for influx happens to live in their repo as well. The Go client has zero dependencies (stdlib only) but Influx's own dependency tree is considerably larger. To prove that the official client has no dependencies:

$ go get -u -v github.com/influxdb/influxdb/client
github.com/influxdb/influxdb (download)
github.com/influxdb/influxdb/client
$ 

Now try goop install on that Goopfile instead. Goop clones influx (as expected), checks it out to the right revision (as expected), but then starts computing the dependency tree for influx itself, and starts cloning all the dependency repositories as well. That ends up failing because influx has a bzr dependency, but the point is that none of those dependencies need to be cloned at all, because my dependency is on the client and not on the parent package.

I was going to ask on the mailing list for influx why the client was moved back into the main repo, but ultimately, this is not their issue. Proper dependency resolution for subpackages is a dependency manager (ie goop) problem.

[petejkim]

thanks, we will investigate this

[pkieltyka]

related: #24