Skip to content
This repository was archived by the owner on Jun 27, 2023. It is now read-only.

Mock import contains "vendor" directory. #30

Closed
PawelAdamski opened this issue Apr 6, 2016 · 9 comments
Closed

Mock import contains "vendor" directory. #30

PawelAdamski opened this issue Apr 6, 2016 · 9 comments

Comments

@PawelAdamski
Copy link

I'm generating mocks using go generate command:
//go:generate mockgen -destination=../../stripe/mock.go -package=stripe bitbucket.org/____/go-lib/model/payment Client

In resulting file imports are:

import (
    payment "bitbucket.org/____/go-lib/model/payment"
    stripe_go "bitbucket.org/____/vendor/github.com/stripe/stripe-go"
    gomock "github.com/golang/mock/gomock"
)

Problematic one is stripe_go which should be github.com/stripe/stripe-go

I tried to add '-imports=stripe_go=github.com/stripe/stripe-go' and '-imports stripe_go=github.com/stripe/stripe-go' but it didn't helped.

@kaedys
Copy link

kaedys commented Apr 11, 2016

Same issue. We've resorted to inserting a sed line in our make generate command:

mockgen $(PROJECT_ROOT)/<file path> <interface(s)> $@ \
&& sed -i '' s,$(PROJECT_VENDOR)/,, $@ \
&& goimports -w $<

Where $(PROJECT_VENDOR) is the path from $GOPATH to and including the /vendor directory in your project (ex. kaedys/foobar/vendor). Alternative, you can just reuse the $(PROJECT_ROOT) variable and add /vendor/ to it, if you so choose.

I've looked over the mockgen.go code, and I can't find a clean place to make this fix (though I didn't spend that much time looking), else I'd put in a PR to fix it.

@rgarcia
Copy link
Contributor

rgarcia commented May 31, 2016

@PawelAdamski @kaedys you might want to try #28

@kaedys
Copy link

kaedys commented Jun 4, 2016

@rgarcia yup, we already rolled that into our internal fork. Also rolled in #25, because why not.

@PawelAdamski
Copy link
Author

@rgarcia Thanks

cpu pushed a commit to letsencrypt/boulder that referenced this issue Nov 23, 2016
The mockgen tool doesn't properly handle[0] Go 1.5 style vendored
dependencies and will emit broken `import`s. We work around this with
sed and tears.

[0] - golang/mock#30
@jecolasurdo
Copy link

Just ran into this issue myself and want to share my workaround as it seems to be a little bit more simple than using sed (as much as I do love sed).

Since we use go generate to run mockgen, we leverage the fact that generate will ignore directories that start with an underscore, and we do the following:

mv src/vendor src/_vendor && go generate ./... && mv src/_vendor src/vendor

When generate runs mockgen, mockgen doesn't recognize there being a vendor directory as it's obscured temporarily. It then correctly resolves the dependencies and generates the correct import statements.

Of course, your directory names and go generate command might differ, but the concept should be portable as a simple workaround. (Might also be a hint towards a solution to the bug.)

@kaedys
Copy link

kaedys commented Oct 11, 2017

@jecolasurdo doesn't that break if the vendored libraries are not present in your gopath, or cause unpredictable results if you have a different version of the libraries in your gopath?

Mockgen functions by creating a new go program (programmatically using the template package) that imports the package being mocked, which then imports the vendored libraries. Renaming the vendor directory to _vendor for the duration of the go generate will cause the vendored versions of those libraries to effectively not exist for the purposes of compiling that generator program, which means it'll either fall back to your gopath version (which might be a different version of that library) or simply fail to compile entirely if absent from there as well.

Anyway, #28 already has a fix for the issue, it just seems to have died in PR.

@mandazi
Copy link

mandazi commented Feb 13, 2018

#28 is now merged. @PawelAdamski I believe that fixes your issue.

@PawelAdamski
Copy link
Author

LGTM thanks @mandazi

keymon pushed a commit to alphagov/paas-billing that referenced this issue Feb 15, 2018
It seems that we are hitting the bug described in [1].

As the fix has not yet been fixed, we would fix it manually
for the time being.

[1] golang/mock#30
@xuchen81
Copy link

I'm running into this issue again.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants