You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Programmatically create a new module with a specified go version and toolchain.
What did you expect to see?
go1.21rc2 mod init -go=1.19 -toolchain=1.19 example.com/foo
What did you see instead?
No new flags.
As someone who creates a lot of module programmatically it would be nice if these things could be specified from the command line as they affect how the module can be used. I could post process these files but that seems like something that should be able to be specified up front.
In particular the go version seem very important to be able to specify given its new constraints it applies in 1.21+.
The text was updated successfully, but these errors were encountered:
I agree that both of these do work but that don't seem like the best user experience imo. If this is the desired experience I feel like it should be documented in go help mod init. But if the point of the mod sub-commands is being able to edit the go.mod files it feels like it should be able to initialize/edit all parts of the file without outside environment/commands being used.
It feels unintuitive for mod init to create a go.mod it won't natively run. GOTOOLCHAIN=go1.x go mod init uses the target toolchain to create the go.mod, matching later behavior when in runs in the newly created module
go mod init is intended to get you into a minimal (default) initial state
I could see this being true for trying to keep it as simple as possible. Just feels odd that I can not get the state I want things in with a single command. Using go get seems fair for setting the go version(although I think this could be documented better) but since you can also declare the toolchain in mod files it seems like there should an similar command for setting the toolchain. Is there a way I am missing?
So I don't think go mod init should have the side-effect of selecting a non-default language or toolchain version.
If there were a flag I would not consider this a side-effect but an explicit handling of what the user wants.
Whoops! I obviously did not read https://go.dev/doc/toolchain closely enough. I had tried a similar command but had left out the go in the version. Since there is a way to edit these programmatically I suppose this is good enough for my use case. Thanks for the clear explanation. I will close this out for now but I do think there may be a docs issue in here somewhere. Maybe some examples in the go help mod?!