counterfeiter does not check vendor directory when generating using import path

[nkovacs]

When you have a vendored library in your project and you use a fully qualified import path to generate a fake, counterfeiter won't search for it in the vendored directory.

E.g.:

mkdir -p vendor/foo/bar/baz/
echo "package baz\ntype Baz interface {\nBaz() string\n}\n" > vendor/foo/bar/baz/baz.go
counterfeiter foo/bar/baz.Baz

Package 'foo/bar/baz' not found on GOPATH

[tjarratt]

So if I understand the use case correctly here ...

There is a vendored library in your project, and it exports an interface. It's their interface that you want to generate a fake for?

I'm not totally opposed to supporting this behavior, but I am amazed at how the complexity of vendor paths and gopaths makes it hard to tell someone simply how counterfeiter searches for code, when you give it a path name. It's getting very, very, very complicated.

One possible alternative to what you've suggested here would be to have your project define a type alias for the interface you want to mock. That way the interface would be in your project, and easier to find. From my own experience, and the teams within cloud foundry, the preferred Go coding style is to define interfaces closer to where you consume them, in the way I've described here.

[nkovacs]

Yes.

[tjarratt]

and just a quick note on the PR for this, #76 - I think this could be useful for other people, but I'm a little concerned about the difficulty of maintaining these changes.

Are you interested in backfilling some unit tests for the changes to the locator package for PRs #74 and #76 ?

[nkovacs]

You're right, it would become more complex, but on the other hand, having it find the package in $GOPATH/src when you're using vendoring is also confusing, and if you have an older, incompatible version of a library in $GOPATH/src, counterfeiter would create the fake, but it wouldn't build, and it wouldn't be obvious why counterfeiter is generating the wrong fake.

I'll try to write some tests, but I don't know when I'll have time to do that. For now I've forked counterfeiter, because I need these fixes for a project I'm working on.

[sysradium]

Is there any progress in solving this?

[chendrix]

Yeah I'd definitely love this behavior :)

[cholick]

Just ran into this issue and your suggested type alias workaround isn't a solution. In my case, I'm pulling in two difference dependencies whose interfaces interact.

[akshaymankar]

Here is an ugly workaround to this problem:

//go:generate counterfeiter -o ./fakes/fake_interface.go ../vendor/github.com/user/library/pkg Interface
//go:generate gsed -i "s|<my-pkg>/vendor/||g" fakes/fake_interface.go

After this running go generate ./... will generate the right fakes.

Note: gsed only works on osx (when gnu-sed is installed), if you want this to work on linux, use sed.

[joefitzgerald]

I think this will be fixed by #94, please check out that PR.

[nkovacs]

This does not seem to be working as expected.

Counterfeiter now uses golang.org/x/tools/go/packages, which does not resolve vendored packages correctly for me. I have to specify the full vendored path, e.g. github.com/someuser/someproject/vendor/github.com/someotheruser/somelibrary.SomeType. If I specify github.com/someotheruser/somelibrary.SomeType, it'll fail if it's not in GOPATH, and if it's in GOPATH, I believe it will use that version, which is also incorrect.

[nkovacs]

This is an issue with go/packages, there's workaround: golang/go#30289