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. On Mon, Aug 16, 2021 at 11:25 PM Nicholas Bunn <nicholasbun...@gmail.com> wrote: > 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? > On Monday, August 16, 2021 at 8:35:15 PM UTC+2 jayc...@google.com wrote: > >> Hi Nic, >> >> This is actually working as intended, though I don't think we've >> adequately documented it. I've sent CL 342531 >> <https://go-review.googlesource.com/c/website/+/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. >> >> On Mon, Aug 16, 2021 at 9:11 AM Nicholas Bunn <nichola...@gmail.com> >> wrote: >> >>> 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 >>> >>> -- >>> 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 >>> <https://groups.google.com/d/msgid/golang-nuts/aa1c413c-f9ab-4be0-822d-4886a37bbdb9n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/88085943-fb64-429d-999b-e0df384d2e33n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/88085943-fb64-429d-999b-e0df384d2e33n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGCADbargYSVVMXm_JjQaLwMW_YkoYVBcfQMZrP-QygDN7Ha3g%40mail.gmail.com.
