Migrate to go modules

[marco-m]

Hello, is there a particular reason for not having migrated to Go modules ?

[petergtz]

Hey @marco-m,

It depends on what you mean by that. If you mean just making the pegomock library use modules, that shouldn't be too difficult.

If you mean that the pegomock tool should understand module-based dependency trees when generating the mock code, that's more difficult depending on the generation mechanism you use.

I personally prefer --use-experimental-modelgen mechanism, because it really parses the code, instead of generating a dummy program and using reflection. To make that work, it looks like a new package, golang.org/x/tools/go/packages, is needed instead of golang.org/x/tools/go/loader and I just haven't gotten this to work yet, and haven't had the time to dive deeper into that.

I tried all that earlier this year, but indeed it's not trivial to do. It's all in the wip-modules branch.

So long story short, reason is I haven't had the time yet :-)

[marco-m]

Hello @petergtz I appreciate you taking the time to give this kind of answers. I agree, while writing this ticket I was telling myself I was not being clear :-)

I meant possibility 1:

just making the pegomock library use modules, that shouldn't be too difficult.

My understanding of the module machinery is that, in addition to the go.mod and go.sum files, to be a good netcitizen the project should bump to version to 3. This is explained in https://github.com/golang/go/wiki/Modules#incrementing-the-major-version-when-first-adopting-modules-with-v2-packages:

If you have packages that have already been tagged v2.0.0 or higher before adopting modules, then the recommended best practice is to increment the major version when first adopting modules. For example, if you are on v2.0.1 and have not yet adopted modules, then you would use v3.0.0 for the first release that adopts modules.

and the examples should use the v3 import path.

I saw the --use-experimental-modelgen option, I will try it.

[yhrn]

I took a stab at this, i.e. "making the pegomock library use modules", but I ran into a problem with the vendor directory. It seems like its existence for a module enabled project is means that go will expect all dependencies to be vendored. And even if that would be ok here running go mod vendor means that the file that is currently there for testing purposes gets deleted since the command will first delete the vendor directory and then build it up from go.mod.

Any thoughts on this @petergtz?

[petergtz]

Hey @yhrn, first of all, sorry for this late response. Been very busy lately.

Then, full disclosure: My main issue right now is, that Go is not my day-to-day programming language anymore and so while I understand the main concepts behind Go modules, I think they have evolved further since I worked on this topic last time.

With that out of the way, some ideas:

1. Have you tried using -mod=readonly or -mod=mod as documented in https://golang.org/ref/mod#vendoring
2. We could consider removing the vendor directory and the corresponding tests and simply not support it. That might a no-go for some users, so we'd have to be careful with that.
3. We could use some real 3rd party library to populate the vendor directory and create a mock for one of its interfaces. This could be a bit brittle, but overall should not affect users.

[yhrn]

No worries @petergtz,

I don't think -mod=readonly or -mod=mod will solve this, it seems to be a build flag so for example it won't help an IDE to find any dependencies. Option 2 seems a bit sad.

Maybe we can do another version of 3. If you could create the repo github.com/petergtz/vendored_package for real instead and just do a go mod init there, create the file currently created dynamically by tests here and finally do a v.0.0.1 version of that repo, then I think we might not need to change any source code here. We would still need to add a real dependency to this new module and vendor all dependencies though.

[petergtz]

Version 3 is now fully migrated to Go Modules. Closing this issue.