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.

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

cmd/go: Go toolchain ./... commands don't work with a combination of sub-modules and go.work file #59610

Closed
agnivade opened this issue Apr 13, 2023 · 7 comments
Labels
GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@agnivade
Copy link
Contributor

agnivade commented Apr 13, 2023

What version of Go are you using (go version)?

$ go version
go version devel go1.21-574c620901 Wed Mar 15 07:15:46 2023 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

This repro needs two repos for it to happen.

  1. Clone https://github.com/agnivade/modbug and https://github.com/agnivade/pgm (just a random repo I had) as sibling directories
  2. cd modbug
  3. Do go list ./... and observe everything work fine.
  4. cd public from there, and repeat go list ./...

Error thrown: pattern ./...: main module (github.com/agnivade/modbug/v7) does not contain package github.com/agnivade/modbug/v7/public/model

Same error with go test ./... as well

Observations

  1. Rename go.work file to something else present under modbug. Things start to work fine.
  2. Providing the package path works. For example go test github.com/agnivade/modbug/public/v7/... works fine from inside public directory.

Notes

  1. Do NOT simply run go mod tidy under modbug. You need to remove the import.go file before that. The expected state of the codebase is to run go mod tidy after removing import.go file. But the import.go file should remain nevertheless. (Yes I know it's weird. It's complicated to explain :P)
@agnivade agnivade added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Apr 13, 2023
@agnivade
Copy link
Contributor Author

cc @bcmills

@bcmills bcmills added this to the Backlog milestone Apr 13, 2023
@bcmills
Copy link
Member

bcmills commented Apr 19, 2023

Is this related to #59480?

@agnivade
Copy link
Contributor Author

No I don't believe so. Here, you are entering that submodule and doing ./... inside that. And this is very specifically related to the presence of a go.work file. Without the go.work file, everything works fine.

@seankhliao
Copy link
Member

So in public, you're in a module, it's a subdirectory under a workspace, but the module isn't listed in go.work.

~/tmp/testrepo0172/modbug/public/model 0:00:00
master » go build     
main module (github.com/agnivade/modbug/v7) does not contain package github.com/agnivade/modbug/v7/public/model

I believe workspace has higher priority than the module, which is why it reports the main module to be the one rooted in the workspace directory (module github.com/agnivade/modbug/v7) and not the one in the nearest parent (module github.com/agnivade/modbug/public/v7).
With that view, the local package can't be part of the main module, because there's still a go.mod carving out a module starting at public.

@seankhliao
Copy link
Member

Sounds like go is inferring the package name for . using just the workspace, which excludes the nearest go.mod.
But giving it the full name works, because it matches via the replaced dependency from the module in the workspace root.

#49632 #51604 are probably related but simpler cases

@agnivade
Copy link
Contributor Author

agnivade commented May 2, 2023

Yes, there is a difference between ./... and <package_path>/....

I need to check if adding use ./public in go.work fixes the issue.

@agnivade
Copy link
Contributor Author

agnivade commented May 3, 2023

Aha! That fixed it. Sorry for the noise. No bug here. But rather a slightly misleading error perhaps.

@agnivade agnivade closed this as completed May 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

3 participants