pegomock: Master incompatible with versioned release

When attempting to use pegomock in CI, we’re pulling pegomock using go get github.com/petergtz/pegomock/... and then generating our mocks with go generate.

However, the latest commits to master are incompatible with the 1.0.0 release from yesterday. Attempting to use them results in:

undefined: pegomock.Option when running tests.

I’d suggest either minting a new release (1.1.0) as a possible option for those of us who can’t lock our go get versions

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 21 (15 by maintainers)

Most upvoted comments

Hey guys,

Thanks, this helps quite a bit. I think I understand the issue now. I didn’t realize that the generate tool is the problem because it’s always on master. I always thought I’d have to make sure old mocks are not broken unless a new major version is introduced.

I must say I didn’t jump on the modules band-wagon yet, because I wanted to wait until it’s more mature. So https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module definitely seems like a solution, but I will need more time to implement this.

Also, @jpopadak, yes, I have also been thinking about separating out the library, but am somehow not convinced yet. I’d be worried that it raises the barrier to using Pegomock the first time.

So to unblock you guys as quickly as possible, I’m wondering if I should simply release a version 2.0.0 that you guys can consume. That way, your library and generate tool are in sync again. You might have to change the version you are tracking, but that sounds doable. Would that work for you?

And yes, @bagmangood, I think I will introduce a development branch somehow, so we don’t get into this ugly unsynced mode between library and tool. Thanks to both of you!

petergtz on Jan 17, 2019

@relnod Just added binaries to release v2.0.1 using goreleaser.

petergtz on Feb 1, 2019

Or there’s always trunk (experimental) vs. master (stable)

bagmangood on Jan 17, 2019

So I am using dep, and since you had no specific version before, dep was tracking master. But then dep today saw the new version, and decided to pull that instead since its a release and not a developer master branch. But even then, if we tracked v1.0.0 in dep, the generator tool is always based upon master with how go get works (you can never pick a specific version unless you’re in a go modules project).

Outside of this behavior, I dont know a great way to do this. And this is something the Go Community has been debating for a very long time. Here is the recommended way if using modules, but it is a goofy way to do it: https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module

jpopadak on Jan 17, 2019