For example the notifications API uses a issues.UserSpec, which is a bit surprising. cc @shurcool
It allowed me to have greater flexibility and control in the issues service definition. The UserSpec was added fairly late in the dev cycle.
The primarily reason I defined it here instead of pulling in sourcegraph.UserSpec is because I wanted the service definition package to be as lightweight as possible, as it currently is:
It imports only one package that isn't standard Go library golang.org/x/net/context, which is necessary and minimal.
If I were to try to use sourcegraph.UserSpec directly in this package, it would cause many, many unnecessary packages to be imported indirectly because of grpc, as you can see here:
That would make it much more difficult for implementations of issues.Service to exist. For example, here's an implementation I made that implements issues.Service from a WordPress export XML file.
In summary, the goal of this package is to define a general and useful interface. The goal of other specific packages that implement the interface is to do so according to their needs; that's why the kv package imports go-sourcegraph and uses sourcegraph.UserSpec there. Does that make sense?
Yes that makes sense. It is frustrating the go-sourcegraph is so heavy weight, especially since most uses don't care at all about gRPC, but rather just the structs themselves. Thanks!