Reducing inheritance of test dependencies

[jsha]

Hi,

Over in Boulder, we're trying to update to the latest certificate-transparency-go. We're having trouble because go mod wants to pull in a lot of dependencies that we don't really want, like BurntSushi/toml, bgentry/speakeasy, coreos/etcd, and more.

I had hoped that https://github.com/google/certificate-transparency-go/pull/630 would fix our issue, since many of those deps seemed to come transitively through golangci-list. However, we still have the same issue.

In general, the unwanted dependencies seem to come largely from tools.go:

import (                                                                                                                                                                                                           
  _ "github.com/golang/mock/mockgen"                                                                                                                                                                               
  _ "github.com/golang/protobuf/proto"                                                                                                                                                                             
  _ "github.com/golang/protobuf/protoc-gen-go"                                                                                                                                                                     
  _ "github.com/google/monologue/incident"                                                                                                                                                                         
  _ "go.etcd.io/etcd"                                                                                                                                                                                              
  _ "go.etcd.io/etcd/etcdctl"                                                                                                                                                                                      
) 

My understanding from https://github.com/google/certificate-transparency-go/pull/529/files is that you're using tools.go with go.mod to manage versions of test dependencies, so you have reliable tests. That makes sense. But as a downstream project, we'd rather not inherit those dependencies (and their dependencies and so on).

Would you consider an alternate strategy for managing test dependencies? For instance, tools.go could become its own go module, in a subdirectory. Or the Travis scripts could go get a specific version of the needed tools at runtime.

Alternately: We depend on a smallish subset of this repo: the client code and its dependencies. Roughly:

github.com/google/certificate-transparency-go/asn1 github.com/google/certificate-transparency-go/client github.com/google/certificate-transparency-go/client/configpb github.com/google/certificate-transparency-go/jsonclient github.com/google/certificate-transparency-go/tls github.com/google/certificate-transparency-go/x509 github.com/google/certificate-transparency-go/x509/pkix github.com/google/certificate-transparency-go/x509util

If you'd be willing to split out the client code into its own repo, that would also probably help solve our problem (under the assumption that the test dependencies for the client code are less extensive).

Thanks for your consideration!

[RJPercival]

We're supportive of the idea of splitting the client code out into its own repo, but don't have the bandwidth to prioritise this work. Would you be willing to undertake it @jsha?

[jsha]

Yep, we'll spend some time on it. I'll close this ticket (about which general approach to take) in favor of #637, where we can discuss specific details of a split-up.