Suggestion to vendor in external deps

[tamccall]

This package relies on several external packages. Namely severeal x/ golang libs that are subject to change and stretchr/testify

Suggestion is to vendor in external deps in order to:

1. ensure more reliable builds.
2. ensure more reliable installation on customer computer

Several tools for this exist in the golang ecosystem( godeps, glide, etc...)

Can we potentially discuss preferred tooling and add a corresponding dependency management tool

[evanphx]

@andymc904 We certainly could vendor it's dependencies, no problem there. For things like stretchr/testify, that's more a dependency on the generated code than the code for mockery itself. There isn't really anything we can do about the versions of stretchr/mock for instance because the project that is using the generated code has to make that decision.

[tamccall]

Well, this package currently uses stretchr/testify in the unit tests for this package so we would probably want to vendor that in as a test dependency. Do you have preference on vendoring tools?

[tamccall]

added pr #138

[alexejk]

I see the PR #138 hanging for a bit now - can it be merged or what's the status?
I believe i'm hitting the problem that this issue is trying to avoid (and thus the PR).

I'm trying to have on-demand installation of tools as per dep documentation for tool dependencies: https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md#required

So in the Gopkg.toml we have:

required = [
    "github.com/vektra/mockery"
]

And then as part of dependecy fetching step we simply run:

dep ensure
cd vendor/github.com/vektra/mockery && go install ./...

This worked OK locally but that is because some of the dependencies were already in $GOROOT/src/, on a CI server however it seems like it's a problem.

mockery/parse.go:15:2: cannot find package "golang.org/x/tools/go/loader" in any of:
	/home/jenkins-user/go/src/github.com/alexejk/my-project/vendor/golang.org/x/tools/go/loader (vendor tree)
	/usr/local/go/src/golang.org/x/tools/go/loader (from $GOROOT)
	/home/jenkins-user/go/src/golang.org/x/tools/go/loader (from $GOPATH)

mockery/generator.go:18:2: cannot find package "golang.org/x/tools/imports" in any of:
	/home/jenkins-user/go/src/github.com/alexejk/my-project/vendor/golang.org/x/tools/imports (vendor tree)
	/usr/local/go/src/golang.org/x/tools/imports (from $GOROOT)
	/home/jenkins-user/go/src/golang.org/x/tools/imports (from $GOPATH)

Vendoring dependencies I believe would solve this problem, as dep would fetch appropriate dependencies and build mockery properly.

Also a side-note that Glide now suggests using dep, as it will most likely be a proper way forward.

[tamccall]

Issue for me is getting go 1.5 to work with the vendor directory. I haven't been working on it too much lately. We either need to get the go 1.5 build working or need to end go 1.5 support. Feel free to pull down that branch and mess around with the go 1.5 build doubt I'll get around with it anytime soon.

[alexejk]

Thanks for the update. Isn't it quite safe to drop 1.5 at this point where 1.10 is coming up?
Also there is a difference in compiling under version 1.5 (to create mockery binary) and supporting version 1.5 for generated sources - or am I wrong?

For example i think dep requires 1.8 to compile from source, but I believe you could use it for e.g 1.7 project still..

[tamccall]

I would say so but that is @evanphx call

[alexejk]

@evanphx Would it be acceptable to drop 1.5 support for compiling this project?
The binary is still usable with 1.5. I've now spent the whole day bashing my head against this with different tools and while the opting into vendor experiment under 1.5 it would seem that go tools behave weirdly during experiment (most likely due to issues that were fixed in 1.6).

I personally do not see the reason for keeping 1.5 support.