hmm that _sort_ of worked? But not

[flat mica]

When you changed to just 1.21 before, did you change both go and toolchain? If not, worth trying to change both

[spiral tiger]

The toolchain was not present. go work use added it

[flat mica]

@hard epoch @north patio @trim sparrow I have some vague memory of a conversation around go.work and needing to update version strings... am I making that up? Does Nipuna's issue ring any bells to anyone?

[trim sparrow]

The only time I can remember is the generated go.mod semver if you're on go 1.20.x

[flat mica]

@spiral tiger there's an update for us to use go 1.21.3 working it's way through CI; once it's published off main I'll give you the command to use it and see if it fixes the problem (for now at least)

But do you have a repo you can share with your setup? I actually don't care about source code per-se, just the go.work+go.mod structure you're trying to use. We need to turn this into a test case if nothing else 🙂 We don't have any coverage yet of using go.work afaik

[hard epoch]

What a confusing message, does it not realize 1.21 is >= 1.21.0? - The only other versioning gotcha I can think of is what Kyle said, where older CLIs don't support triple-segment versions

Feels like it could be a bug in Go, some piece of code that's not aware of the new semver format

[flat mica]

@spiral tiger there's an engine image published off main w/ go sdk using 1.21.3 now, you can use it w/ the v0.9.1 dagger CLI by exporting this env var:
export _EXPERIMENTAL_DAGGER_RUNNER_HOST=docker-image://registry.dagger.io/engine:main@sha256:b549395e6cc27e803e179258c9ef4441a13fa879521ace8007d96ba9837034b0

[spiral tiger]

Hey Eric, I will try that! I signed off for the day before I saw your message. I can show you a tree of how my directory structure looks like but I don't have the code hosted in a public accessible repo.

[spiral tiger]

@flat mica Here's a snapshot of my dir structure