You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Do go list ./... and observe everything work fine.
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
Rename go.work file to something else present under modbug. Things start to work fine.
Providing the package path works. For example go test github.com/agnivade/modbug/public/v7/... works fine from inside public directory.
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)
The text was updated successfully, but these errors were encountered:
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.
So in public, you're in a module, it's a subdirectory under a workspace, but the module isn't listed in go.work.
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.
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.