Go mod ignoring project sub-modules

[Nicholas Bunn]

Hi all,

Hoping someone can give me a bit of assistance here. I'm busy refactoring a gRPC project of mine so that all proto files are generated into a single, "protoFile" directory, instead of having the generated files living under the service's directory. My idea is to have the generated files implemented as modules, allowing any client to access them from this central location.

The issue I've run into is the "module found ... but does not contain ..." one. I've hit this a couple of times before (as anyone new to Go modules does, I'm sure) and can usually solve it by cleaning modcache and/or re-initialising the modules. However this time the usual solutions haven't helped much. I've attempted to implement semantic versioning on my Github too, which didn't resolve anything either. Go get fetches the correct version of my project directory (github.com/NicholasBunn/mastersCaseStudy), but when I check my pkg directory, it's omitted all subfolders that contain Go modules (including all go services with a go.mod file). 

The project is hosted at github.com/NicholasBunn/mastersCaseStudy, with the generated protos living in protoFiles/go. If you'd like to try and re-create the issue, cd into mastersCaseStudy/services/authenticationService, and run "go mod tidy". This service makes use of the generated protos living in mastersCaseStudy/protoFiles/go/authenticationService/v1, which has its go.mod and go.sum files, but the "go mod tidy" fails on my side with the error mentioned above.

Hoping I've just misunderstood something with Go modules and someone here can throw me onto the right path again!

Thanks in advance,

Nic

[Jay Conrod]

Hi Nic,

This is actually working as intended, though I don't think we've adequately documented it. I've sent CL 342531 to mention this in the reference documentation.

In short though, files in a subdirectory that contains a go.mod file are considered part of a different module, so when you download the module in the parent directory, the files in that subdirectory are not included.

In many cases, putting multiple Go modules in the same repository can be counter-intuitive. I'd only recommend it in situations where you have multiple projects that need to be released and versioned independently. If the projects are tightly couple and need to be released together it may be better to have them in one module.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/aa1c413c-f9ab-4be0-822d-4886a37bbdb9n%40googlegroups.com.

[Nicholas Bunn]

Thanks for the prompt response, Jay!

And thanks for clearing that up, it's good to know that it's intended to run as such. For the purpose and scale of this project, it's a bit easier to keep everything together and use sub-modules where I can (this hasn't been an issue thus far) so I'd like to keep it this way if possible. If I do stick with this approach, how could I work around this? Intuitively, I'd just install the sub-modules individually - but this is what produced my issue in the first place. Is there a way I can force the modules to exist on their own instead of as modules in a subdirectory?

[Jay Conrod]

If you are using submodules, the best way to do that is to treat each modules as a separately versioned, releasable unit. So each module has a "require" directive for other modules it needs at the minimum usable version (managed with 'go get' or 'go mod tidy'). You can tag versions for each submodule by adding a directory prefix in front of the tag. For example, if you have a module in subdirectory "a/b", the tag would look like "a/b/v1.0.0". You don't have to tag of course; pseudo-versions referring to commits still work fine.

This makes coordinating changes across modules a bit cumbersome though. For example, if you have a module A that depends on module B, and A needs a bugfix in B, you'll probably want to 1) add local replace directives in A and B, 2) make the change in both and confirm it works, 3) remove the replace directives, 4) commit the change in B, 5) tag a release in B, and 6) update A's dependency on B.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/88085943-fb64-429d-999b-e0df384d2e33n%40googlegroups.com.

[Nicholas Bunn]

Aah okay, I've got it working now - thanks! Not going to run tags just to make things easier, but I'll be the sole developer for a good while so it shouldn't be too much of an issue (and it's self-inflicted, if it is)!

Thanks again for the assistance