I am trying out the go support and have run into a...
# general
l
I am trying out the go support and have run into an error I don't understand. When running basically any pants command, I get this error:
Copy code
ProcessExecutionFailure: Process 'Run `go list` to download and analyze all third-party Go packages' failed with exit code 1. ...  

...
go: updates to go.mod needed, disabled by -mod=readonly; to update it:
	go mod tidy
Yet
go list
on its own doesn't cause errors. And
go mod tidy
doesn't show any changes.
h
Hm can you try
go mod download all
and
go mod tidy
? We found it's sometimes necessary to run both We know this error message is confusing https://github.com/pantsbuild/pants/issues/13136
also what Go version is this?
l
Copy code
$ go version
go version go1.17.5 darwin/amd64
just ran
go mod download all
and
go mod tidy
and same result
f
try just
go mod download all
👆 1
and what version of Pants?
h
Hm frustrating, we're still trying to figure out a better story for this until pants can manage
go.mod
for you... So I think the next best thing to debug would be using
--no-process-cleanup
(
--no-process-execution-local-cleanup
if on Pants 2.8). It will log something like this:
Copy code
16:06:37.48 [INFO] Preserving local process execution dir /private/var/folders/g7/0lj2pw4d6db67tm8m8xj0rc80000gn/T/process-execution5P1osZ for "Run `go list` to download testprojects/src/go/go.mod"
If you cd there, you can modify the
__run.sh
script to not use
-mod=readonly
and see how it changes the
go.mod
l
@fast-nail-55400 I did just that command and it still fails
version 2.8.0
f
can you share the full log? (and redact any confidential data)
preferably with
-ldebug
for debug logging
l
@hundreds-father-404 after updating __run.sh I get:
Copy code
$ sh __run.sh
go: updates to go.mod needed; to update it:
	go mod tidy
@fast-nail-55400 regular output https://gist.github.com/ryanking/75d3ed1bee22d38e28ec721c252b3d17 let me know if you want debug logs
maybe interesting exception from the pants.log: https://gist.github.com/ryanking/0e41b6cb27cef2c2b9f2cadb12e75bcd
f
are you able to share the go.mod and go.sum files? (can use DM or email to keep private). I’d like to try and reproduce the issue locally.
l
dm'd
f
thanks. I’m able to reproduce. Will dig in tomorrow.
(It also reproduces with latest
main
branch.)
👍 1
running
go list -e -json -mod=mod ...
updates the go.mod to include indirect deps
go mod tidy
was not helpful because my minimal module caused
tidy
to remove all unused modules (i.e., all of them)
h
Did
go mod download all
still not do the trick?
That's interesting, sounds like go list -e -mod=mod ... is the solution we want to tell people to do. Don't suggest go mod tidy or anything
f
go mod download all
filled in some missing
go.sum
entries but it didn’t add indirect modules to the
go.mod
I’m leaning toward us re-introducing the
go-resolve
goal to handle this for the user
👍 1
h
Yeah maybe we should do that until we have time to unify with the generate-lockfiles goal
This is too confusing otherwise. And we punted on improving the error message because that itself would take some time to do. Probably the same amount of time as implanting the goal
l
thanks for following up on all of this
coming back to this now, what I am seeing– If I run a pants command (tailor in this case, but really anything that reads config for the go targets) I get an error telling me to run
go mod tidy
. If I ignore that and run
go mod download all
some entries get added to go.sum, but when running pants I still get the error telling me to run
go mod tidy
, which removes the entries added by
download all
.
1
h
and what about if you run
go list -e -mod=mod ...
?
l
it seems to work?
not sure if the results are expected tho
h
How so? Iiuc it will add more
// indirect
entries to
go.mod
than you'd normally have
l
oh good point. I didn't look at go.sum, just stdout
note that unlike
download all
go list -e -mod=mod ...
updated go.mod, not just go.sum. maybe that is my problem?
1
h
From what Tom reported, I think
go mod download all
and
go list
will update
go.sum
the same way. The only difference otherwise is that
go list
adds more indirect entries to
go.mod
But yeah, this is all so confusing and I agree with Tom that we should have Pants manage this all for you
f
longer term, we should figure out why
go build
doesn’t seem to add these entries when run outside of Pants
I surmise that it is probably because of the way Pants uses
go list
to analyze third-party dependencies
1
l
Following up on this - It seems that the problem is that pants wants to have all indirect dependencies in go.mod, but most of the go ecosystem doesn't work that way.
h
Yeah, I think that's right. And we do that to know about the "universe" of third-party Go packages in your project so that we can do things like dependency inference -- to get that metadata, we run
go list ...
We know one issue is how confusing it is to generate the right `go.mod`/`go.sum` - which we should probably workaround by having Pants generate for you. But other than that, is this causing issues with interoperability with the rest of the Go ecosystem? That having this more exhaustive `go.sum`/`go.mod` will fundamentally be a problem?
l
fundamentally no, but every project I have worked on and many default linters want
go mod tidy
to be run
1
out-of-the-box config in vs code–
so not fundamentally wrong, but gonna be annoying for a lot of people
h
Great point, I agree with you there
https://github.com/pantsbuild/pants/issues/14071 If you had the interest and time to try out the questions in "possible solution", that would be super helpful. From there, it wouldn't be that hard to update Pants to use the new approach
👀 1
l
spent some time on it and didn't come up with anything great
other that maybe reading go.sum or using
go list -f "{{.ImportPath}} {{.Deps}}" ./...