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.work library path parsing error causes build failed #54611

Closed
ghost opened this issue Aug 23, 2022 · 10 comments
Closed

cmd/go: go.work library path parsing error causes build failed #54611

ghost opened this issue Aug 23, 2022 · 10 comments
Labels
FrozenDueToAge GoCommand cmd/go 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

Comments

@ghost
Copy link

ghost commented Aug 23, 2022

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

$ go version
go version go1.19 darwin/arm64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE="on"
GOARCH="arm64"
GOBIN="/Users/hanlei/go/bin"
GOCACHE="/Users/hanlei/Library/Caches/go-build"
GOENV="/Users/hanlei/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/hanlei/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/hanlei/go"
GOPRIVATE="github.com"
GOPROXY="https://goproxy.cn"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/work/code/gotest/workspace/go.mod"
GOWORK="/Users/work/code/gotest/workspace/go.work"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/p9/h206g_9n4glgjth2qqcpgsbm0000gn/T/go-build2550634632=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

iShot_2022-08-22_20 42 08

  1. i created main.go, referenced the online library, and output the timestamp.
  2. go build, build successful.
  3. i created go.work, reference the local library.
  4. go run main.go and output local changes.
  5. go build, build failed.

What did you expect to see?

  1. i would like to know what is the reason for the failure.
  2. How to use go work to compile and pass.
  3. Why can't it run and compile when no library is referenced in go.work
  4. I want to know that the local library path I use in go.work is an absolute path, why the path will be resolved incorrectly when building

What did you see instead?

build failed

@ghost ghost changed the title affected/package: affected/package: go.work library path parsing error causes build failed Aug 23, 2022
@ianlancetaylor ianlancetaylor changed the title affected/package: go.work library path parsing error causes build failed cmd/go: go.work library path parsing error causes build failed Aug 23, 2022
@ianlancetaylor ianlancetaylor added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Aug 23, 2022
@ianlancetaylor ianlancetaylor added this to the Backlog milestone Aug 23, 2022
@ianlancetaylor
Copy link
Contributor

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

@ghost
Copy link
Author

ghost commented Aug 23, 2022

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?

@bcmills
Copy link
Member

bcmills commented Aug 23, 2022

@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.

@bcmills
Copy link
Member

bcmills commented Aug 23, 2022

@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 bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 23, 2022
@ghost
Copy link
Author

ghost commented Aug 24, 2022

@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.

@ghost
Copy link
Author

ghost commented Aug 25, 2022

I have the new questions:
image

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

@bcmills
Copy link
Member

bcmills commented Aug 25, 2022

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.

@ghost
Copy link
Author

ghost commented Aug 29, 2022

image

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

@bcmills
Copy link
Member

bcmills commented Aug 29, 2022

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).

@bcmills
Copy link
Member

bcmills commented Aug 29, 2022

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).

@bcmills bcmills closed this as not planned Won't fix, can't repro, duplicate, stale Aug 29, 2022
@golang golang locked and limited conversation to collaborators Aug 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge GoCommand cmd/go 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
Development

No branches or pull requests

3 participants