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: builds fail when GOPATH=/dev/null #31100

Closed
josharian opened this issue Mar 28, 2019 · 5 comments

Comments

Projects
None yet
4 participants
@josharian
Copy link
Contributor

commented Mar 28, 2019

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

@cuonglm

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

commented Mar 28, 2019

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

This comment has been minimized.

Copy link

commented Mar 28, 2019

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

@josharian

This comment has been minimized.

Copy link
Contributor Author

commented Mar 28, 2019

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

@gopherbot gopherbot closed this in d2cb5b7 Mar 28, 2019

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…
…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 <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.