Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error when running against mod with vendoring enabled #689

Open
1 of 5 tasks
bzumhagen opened this issue Aug 8, 2023 · 6 comments
Open
1 of 5 tasks

Error when running against mod with vendoring enabled #689

bzumhagen opened this issue Aug 8, 2023 · 6 comments

Comments

@bzumhagen
Copy link

PLEASE READ

DO NOT submit tickets without first using the latest version of Golang, clearing your local golang package cache, and re-building mockery using the latest Golang version and the latest version of mockery. Please provide evidence this has been done in your issue. Failure to provide this evidence will likely result in your issue being closed.

Description

When trying to run mockery against a golang mod project with vendoring enabled, I get an error.

Mockery Version

v2.23.4

Golang Version

Whatever version is in the docker image vektra/mockery:v2.23

NOTE: Please upgrade to the latest golang version before submitting tickets!

Installation Method

  • Binary Distribution
  • Docker
  • brew
  • go install
  • Other: [specify]

Steps to Reproduce

  1. Navigate to a go module project dir
  2. docker pull vektra/mockery:v2.23
  3. docker run -v "$PWD":/src -w /src -e GOFLAGS=-mod=vendor vektra/mockery:v2.23

Expected Behavior

I expect mockery to run successfully

Actual Behavior

[what actually happened]

08 Aug 23 18:47 UTC INF Starting mockery dry-run=false version=v2.23.4
08 Aug 23 18:47 UTC INF Using config: /src/.mockery.yaml dry-run=false version=v2.23.4
error occurred when loading packages
08 Aug 23 18:47 UTC ERR encountered error when loading package error="-: cannot query module due to -mod=vendor" dry-run=false version=v2.23.4
08 Aug 23 18:47 UTC ERR unable to parse packages error="error occurred when loading packages" dry-run=false version=v2.23.4
@LandonTClipp
Copy link
Collaborator

Can you provide the contents of your config file?

@bzumhagen
Copy link
Author

bzumhagen commented Aug 9, 2023

Below is the redacted config

with-expecter: True
packages:
  github.com/myenterpriseorg/myprivaterepo:
    interfaces:
      MyFooBarInterface:

Basically just copied from the docs and slightly tweaked

@LandonTClipp
Copy link
Collaborator

We don't have an established pattern for vendored deps. I really want to fix this for you but I don't have an answer at the moment. If someone could chime in with what worked for them, I can get it added to the docs and/or make the relevant code changes we need.

@bzumhagen
Copy link
Author

@LandonTClipp I did some more digging into it and discovered it's actually a misleading error message.

The issue is that the package I had listed in the .mockery.yaml didn't have any go files directly under it, so I think packages.Load tries to run a fallback command which then spits out that message.

When I adjusted the .mockery.yaml to use a package that had go files under it, the error went away.

I'm not sure exactly how I would adjust this, maybe display an additional message with the errors indicating that no files were found for the specified package.

But for any future spelunkers, if you get either of these error messages

ERR encountered error when loading package error="-: cannot query module due to -mod=vendor\n\t(Go version in go.mod is at least 1.14 and vendor directory exists.)"

or

ERR encountered error when loading package error="-: cannot query module due to -mod=vendor"

check all your package paths to make sure they have go files

@Luukvdm
Copy link

Luukvdm commented Aug 14, 2023

Just an exclude parameter should fix this I think. Although excluding the vendor dir by default also makes sense.

Are you sure your error wasn't caused by a combination of those two problems? @bzumhagen
I also ran into this and I am currently using the same workaround.

@bzumhagen
Copy link
Author

It could be a combination for sure, I didn't try to suss out exactly what lead to it.

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

No branches or pull requests

3 participants