cmd/go: a parent module does not seem to require a child

[jeanbza]

I'm not sure whether this is WAI or not, so I thought I'd open an issue in case it's not WAI.

We have a project called gax-go that accidentally has a v2 tag (from the dep days). Some of our other libraries, such as google-cloud-go, depend on this library and accept gax-go types as arguments to functions in google-cloud-go. We want to support both of our gax v1 and gax v2 users, but we also want to support go modules in gax-go.

Here's what we expected to happen:

• Create v2/ directory in gax-go, copy contents of parent into v2/, and create v2/go.mod

• Commit, push, tag v2.0.1

• Turn all parent types into type aliases of v2 counterparts, and all functions into shallow functions of v2 counterparts

• Add go.mod to parent with a require statement for the child, e.g.

  module github.com/googleapis/gax-go
  
  require github.com/googleapis/gax-go v2.0.1
  

• Commit, push, tag v1.0.1

However, we got to the part where we create a parent go.mod and then go mod tidy removes the require github.com/googleapis/gax-go v2 statement.

This is very strange. The parent certainly does require the child (all parent types are aliases of child types at this point). Furthermore, the child is its own submodule AFAICT - it has its own go.mod. So, why does go mod tidy not like the require v2 statement?

Is my understanding incorrect: that a go.mod indicates a new submodule unless it's a v2, in which case there's some special relationship causing the v1 version to somehow implicitly knows about v2 (and subsequent versions, I guess?)?

Or perhaps is there user error in my order of steps?

[bcmills]

require github.com/googleapis/gax-go v2.0.1

That declaration is inconsistent: semantic import versioning requires that the module path for a module at v2.0.1 end in /v2, but the require line refers to the non-v2 module (in this case, the module path for the main module containing the go.mod file itself!).

[bcmills]

The rest of the steps you've described seem correct. Does it work as expected if you change that line to

require github.com/googleapis/gax-go/v2 v2.0.1

and change the corresponding module definition in v2/go.mod to

module github.com/googleapis/gax-go/v2

?

[jeanbza]

@bcmills The module definition thankfully is already /v2. I tried require github.com/googleapis/gax-go/v2 v2.0.1 and I experienced the same behavior: go mod tidy blew it away.

Also, TIL that the require definition must include the major version in the path. I guess that makes sense in hindsight.

[bcmills]

Did you remember to update the import paths to use the /v2 suffix before running go mod tidy?

(A concrete list of commands would be helpful, although I realize that's tricky when one of your steps is “commit, push, tag”.)

[jeanbza]

Did you remember to update the import paths to use the /v2 suffix before running go mod tidy?

(A concrete list of commands would be helpful, although I realize that's tricky when one of your steps is “commit, push, tag”.)

Yes. PTAL googleapis/gax-go#61.

Could this issue possibly be related to #28083?

If needs be, I can list a series of commands that reproduce this issue.

[bcmills]

Hmm, I don't see a go.mod file in googleapis/gax-go#61, and I can't reproduce the problem with a local change.

My attempt at replicating your PR from scratch builds and passes its tests in module mode.
(bcmills/gax-go@619d4b9)

[jeanbza]

What in tarnation. This must be user error - apologies! A fresh look does show no go.mod (what?), but adding it clearly makes the parent depend on the child. All is well. Sorry to have wasted your time.