(I'm not following the bug template here because this is more of a documentation issue)
I have an internal library which needs to provide versions in multiple languages. So for example, the Python implementation lives in /python. I recently was given responsibility for the Golang implementation, which lives in /golang.
I have been having a lot of difficulties importing this library from another Go program I've been trying to migrate to Go modules. One thing I noticed ahead of time might be an issue is that the go.mod file isn't in the root of the git repo.
I checked with someone who knows a lot about multi-module repos (way more than me, at least) and they said you have to prefix it with the subdirectory.
I think it should be better documented that the caveats here - needing to tag versions in a special way, etc. - also apply to any repo which doesn't have go.mod in the root directory, even if they only have a single Go module.
(I mean, if we want to have a broader discussion of whether or not we want to change this behavior somehow, this issue can also be the place for that).
The text was updated successfully, but these errors were encountered:
In the major subdirectory convention, v2/ contains the module "my/thing/v2". A natural extension is to allow subdirectories not named for major versions. For example, we could add a blue/ subdirectory that contains the module "my/thing/blue", confirmed by a blue/go.mod file with that module path. In this case, the source control commit tags addressing that module would take the form blue/v1.x.x. Similarly, the tag blue/v2.x.x would address the blue/v2/ subdirectory. The existence of the blue/go.mod file excludes the blue/ tree from the outer my/thing module.
In the Go project, we intend to explore using this convention to allow repositories like golang.org/x/text to define multiple, independent modules. This lets us retain the convenience of coarse-grained source control but still promote different subtrees to v1 at different times.