https://pantsbuild.org/ logo
Join Slack
Powered by
<@U0N6C2Q9F> re Go version handling:
# development
h
@fast-nail-55400 re Go version handling:
1. I think it would be cool if we do indeed go back to downloading Go for you. Although, until we have Pants generating the lockfile for you, I am a bit hesitant because it increases the risk of the user using a different version of Go when running 
go mod download all && go mod tidy
. We also need to figure out how to model it, I think in the past we said you shoudl be able to either have Pants download or use from machine 2. In the meantime, how about changing 
[golang].expected_version
to be the minimum expected version. If you have Go 1.18, that should work with 1.17 thanks to backwards compat. It's too brittle rn.
f
re 1: I’m fine with that. That would point to a 
go-resolve
or other goal to do the resolution for you. We are actually in a position now to check wether go.sum entries are missing for a module. And we could do something similar to Bazel gazelle to run 
go mod download
to fill in missing go.sum entires (during a 
go-resolve
run only).
re (2): The semantic would align 
expected_version
with how the 
go
directive in 
go.mod
works
👍 1
“A 
go
directive indicates that a module was written assuming the semantics of a given version of Go.” https://go.dev/ref/mod#go-mod-file-go
h
K, I'll start with 2 because 1 is more involved. For 2, I was thinking we might want to rename the option to something like 
minimum_version
, but imo we shouldn't rename until we figure out:
We also need to figure out how to model it, I think in the past we said you shoudl be able to either have Pants download or use from machine
Open in Slack
PreviousNext
Powered by