Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
jeanbza opened this issue Nov 14, 2018 · 7 comments
Closed

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

jeanbza opened this issue Nov 14, 2018 · 7 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Go1.13

Comments

@jeanbza
Copy link
Member

jeanbza commented Nov 14, 2018 •
edited

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?
@jeanbza jeanbza mentioned this issue Nov 14, 2018
Merged
@bcmills
Copy link
Contributor

bcmills commented Nov 14, 2018

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
Copy link
Contributor

bcmills commented Nov 14, 2018

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

?

@bcmills bcmills added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Nov 14, 2018
@bcmills bcmills added this to the Go1.13 milestone Nov 14, 2018
@jeanbza
Copy link
Member Author

jeanbza commented Nov 14, 2018 •
edited

@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
Copy link
Contributor

bcmills commented Nov 14, 2018

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
Copy link
Member Author

jeanbza commented Nov 15, 2018

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
Copy link
Contributor

bcmills commented Nov 15, 2018

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
Copy link
Member Author

jeanbza commented Nov 15, 2018

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.

@jeanbza jeanbza closed this as completed Nov 15, 2018
@golang golang locked and limited conversation to collaborators Nov 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Go1.13
Development

No branches or pull requests
3 participants
@jeanbza @bcmills @gopherbot