Consider merging hubclient and hubapi package to only need one import

[brekelj1]

Is there any reason the hubapi and hubclient packages are separate? If users want need to declare response types then they have to additionally import the hubapi package. It would be easier for users in this case to only have to import one package.

[tandr]

Some places need only hubapi packages with definitions only, and don't want to pull http client part with all of associated dependencies

[brekelj1]

Hi @tandr I don't think placing packages in different directories of the same repository achieves what you want. I believe the go tools checkout the repository at a given commit, and then use that checkout to resolve directories within the package's repository. I.e. import "bla.com/pkg.git/bla" will result in the repository bla.com/pkg.git being cloned, and then it looks for the bla directory in the checkout.

[tandr]

So... I have a package that uses only hubapi because I need definitions of the structures only (to parse json). I don't need the http client stuff. Right now it will be just one directory in my vendor directory. Putting them together will make me to pull dependencies that I don't need at all just to compile my project.

[brekelj1]

You are right that go tools won't copy the files in the vendor directory, but:

1. Go tools will still download those files, as mentioned above (which takes the most time).
2. The go compiler won't compile code that is not imported.

If you are worried about bloating pull requests with vendored files: go modules (in combination with a go proxy?) enables you to remove vendored files (but I appreciate that maybe your environment has other constraints).

It is common for google client packages to follow this approach, for example:

1. https://github.com/google/go-github/tree/master/github
2. https://godoc.org/google.golang.org/api/compute/v1