Please include the errors as plain text, not as images. Images are very difficult to read, and there is no reason to use them for plain text. Thanks.

CC @matloob @bcmills

lib.GetSecondTimestamp:

func GetSecondTimestamp() int64 {
fmt.Println("111111111111111"). // the line only native code exists.
return time.Now().UnixNano() / 1e9
}

main.go:

func main() {
unix := lib.GetSecondTimestamp()
fmt.Println("unix:", unix)
}

go.work:

go 1.19

use /Users/work/code/ai/golib // the path is local absolute path

when i use go.work, go build fails, The error message is directory . is contained in a module that is not one of the workspace modules listed in go.work. You can add the module to the workspace using go work use .

The path used in go.work is a local absolute path. Why does this error occur when using go build?

@hlbbt, when you invoke go build without arguments, it implicitly builds the package in the current working directory.

You are invoking go build in the directory /Users/work/code/gotest/workspace, which is not in the module rooted at /Users/work/code/ai/golib (because gotest/workspace is not contained within ai/golib). That's what the error message is trying to tell you.

@hlbbt, there is a tutorial on using modules in https://go.dev/doc/tutorial/create-module, and one on workspaces in https://go.dev/doc/tutorial/workspaces. I would suggest working through those as a starting point, and hopefully it will help to clarify how workspaces are intended to be used.

Once you've worked through those, please let us know if there are specific steps we can take to better clarify the documentation or error messages.

@bcmills I seem to understand the concept of workspace, It needs to contain go.work in a root directory, all projects are at the same level as go.work, and then use defferent project packages in go.work.

Re-tested, compiled and passed, and also met my work requirements. Very thanks.

I have the new questions:

I completely refer to the official example, go work works fine, but when I add a new project in the workspace, if the project path is not used in go.work, the project fails to build.(eg. the step 2)

I think go.work is a supplement to the workspace, and my build fails because my original project path is not used in go.work, Otherwise I have to add all my project paths to go.work which is unreasonable.

Another question: the local public package is referenced in go.work, and the online public package is required in the project.
When I click to jump to the function, should I display the local package function and the online package function together? You can check whether the function is with modifications

Otherwise I have to add all my project paths to go.work which is unreasonable.

I don't agree that it's unreasonable, and it's how workspaces were designed in the proposal that was approved.

If you have a lot of interrelated packages or interrelated programs, consider them putting them together in one larger module instead of stitching together a bunch of smaller ones into a workspace.

When I click to jump to the function, should I display the local package function and the online package function together?

It should display whatever version of the function is actually used in your current configuration. If you have gopls configured to use workspaces, then it should show the definition found within the workspace.

I have a scene like this:
/Users/work/code/ai This path is the root directory of all projects,
Each folder in this directory is a project, and they all reference the golib project,
At this time, I create go.work in the ai directory. When I want to build/debug any project, I must add the project to go.work, but only one of the projects may use the modifications in the local golib. Other projects still use the online extension package referenced in go.mod

I don't know if there is a better solution for this scenario, or use the replace in go.mod in their respective projects

If you want to modify a package and have all of its consumers see the changes, you will need to either push the changes and update the consumers' go.mod requirements (for example, using go get -u ./...), or pull in the changes in the consumer modules in some other way (by defining a workspace that includes the module with the changes, or by using a replace directive).

That said, I don't think the issue tracker is the right forum to continue this discussion. It seems like the go command is parsing and interpreting the go.work file as designed. I'm happy to continue it in some other venue (such as the golang-nuts mailing list or the #modules channel of the Gophers Slack).