How can I make go pick the right version when using 'dev'?

[fredrikaverpil]

I've got a project with a go.mod file which specifies go 1.17. Should this not be detected automatically (when dev has been run in the project) and make sure Go version 1.17 is active?

What's a good way to tell this specific project of mine to use Go 1.17?

[jhheider]

dependencies:
  go.dev: ~1.17 # or, e.g., =1.17.2

looking at

pkgx/src/utils/devenv.ts

Lines 57 to 61 in 7a488fd

	case "go.mod":
	case "go.sum":
	pkgs.push({project: "go.dev", constraint})
	await read_YAML_FM(path)
	break

, pkgx only adds go.dev: '*', but doesn't parse go.mod. personally, i'm torn as to whether that is strictly a good move. while go.mod does define a go version, it's often possible it work with other go versions, and i can definitely see developers wanting to be able to switch/test more easily. usually, when in doubt, we err on the side of user-configurability.

what do you think? is the ability to set complex version requirements using pkgx.yaml worthwhile here?

[fredrikaverpil]

Good question. Let me ask some colleagues, gather some more input, and I'll get back to you with what we think.

[jhheider]

sounds like a plan. we've been trying to walk a fine balance here. as an example: we has a user who has to use a patched version of yarn for their project, but pkgx detects yarn.lock and adds our version to their environment. so, each invocation, they have to do env -yarnpkg.com to get correct functionality. i worry we'd be buying something like that with parsing go.mod.

but, of course, we do parse the engines key of package.json, though it often specifies semver ranges. just the various considerations at play.

[fredrikaverpil]

I think let's not do anything about this. I'm still new to both Go and pkgx and I can easily work around this by adding a pkgx.yml file if I actually want Go to pick another version.

I appreciate the conservative approach here.

[jhheider]

excellent. yes, it's a fine line between helping people work more easily and locking them into things they don't want.

[mycrEEpy]

Just for information, since Go 1.21 we have toolchain management which basically makes it obsolete to have the "correct" Go version installed locally.

[Aditya-doid]

Good question..i iwait