Skip to content

cmd/go: builds fail when GOPATH=/dev/null #31100

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
Closed
josharian opened this issue Mar 28, 2019 · 5 comments
Closed

cmd/go: builds fail when GOPATH=/dev/null #31100

josharian opened this issue Mar 28, 2019 · 5 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.
Milestone
Go1.13

Comments

@josharian
Copy link
Contributor

josharian commented Mar 28, 2019 •
edited
Loading

When run with GOPATH=/dev/null, go build fails:

$ GOPATH=/dev/null go test -run=TestLldbPython -v -count=1 runtime
=== RUN   TestLldbPython
--- FAIL: TestLldbPython (0.21s)
    runtime-lldb_test.go:169: building source exit status 1
        go: failed to create cache directory /dev/null/pkg/mod/cache: mkdir /dev/null: not a directory
FAIL
FAIL	runtime	0.220s

That seems fine. Who would run with GOPATH=/dev/null‽ It's not even a directory.

But it's not fine, because run.bash sets GOPATH=/dev/null. Why? The comment says: The $GOPATH value doesn't need to point to an actual directory, it just needs to pass the semantic checks performed by Go.

I don't know who is wrong here, but I do want all.bash to pass. I have a workaround I can mail just for TestLldbPython (set GOPATH=). Or we can fix this mess...somewhere else.

Opinions?

@bcmills @jayconrod @bradfitz
@josharian josharian added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Mar 28, 2019
@josharian josharian added this to the Go1.13 milestone Mar 28, 2019
@cuonglm
Copy link
Member

cuonglm commented Mar 28, 2019

@josharian IMHO, set GOPATH=/dev/null in run.bash prevent it from conflict with GOROOT. If the test required a valid GOPATH, it should set explicitly.

@bcmills
Copy link
Contributor

bcmills commented Mar 28, 2019

GOPATH/pkg/mod contains the module cache, which includes a lockfile that guards edits to the user's go.mod and go.sum files (see cmd/go/internal/modfetch.SideLock).

If those files do not need to be updated and no modules need to be downloaded, then the lock does not need to be acquired, and GOPATH does not need to be set. I'm guessing that the failure you're observing is an interaction with #30790, which perhaps introduces more edits to the go.mod file than strictly necessary.

Regardless of the cause, we could proceed without locking if GOPATH does not exist and cannot be created, but I think an explicit failure in that case is preferable to an undetected race.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/169877 mentions this issue: cmd/go/internal/modload: do not implicitly add a 'go' directive to an existing go.mod file

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/169918 mentions this issue: runtime: fix TestLldbPython in module mode (again)

@josharian
Copy link
Contributor Author

Thanks. I went ahead and mailed my simple workaround for you to take a look at.

gopherbot pushed a commit that referenced this issue Apr 19, 2019
cmd/go: only add a 'go' directive on 'go mod tidy' or when a conversi…
a1c481d 
…on occurs

If the go.mod file exists and is empty, we initialize it from any of
various formats supported by legacy dependency-management tools.

We also initialize the 'go' directive at that point: we know that the
go.mod file is incomplete, because it does not reflect the information
in the legacy configuration file, and since we know that the go.mod
file is incomplete, we should complete it with as much information as
we have — including the version of the language currently in use.

However, if there is no legacy configuration file present, then we
cannot infer that the go.mod file is incomplete: it may correctly
specify a module without external dependencies. In that case, we
should not initialize the 'go' directive either: the user will not be
expecting unnecessary edits to the go.mod file, and we generally do
not make unnecessary-but-helpful edits unless 'go mod tidy' is invoked
explicitly.

Fixes #30790
Fixes #31100

Change-Id: I05a7872bce54a917c10d910cd9a616cab52e2730
Reviewed-on: https://go-review.googlesource.com/c/go/+/169877
Run-TryBot: Bryan C. Mills <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
@golang golang locked and limited conversation to collaborators Mar 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.13
Development

No branches or pull requests
4 participants
@josharian @cuonglm @bcmills @gopherbot