feat: remove go aliases

[jedevc]

Completes the work from #6680 by removing the aliases, which were really tricky to work with from a code completion perspective.

By using #7759, we can avoid breaking the daggerverse, and just apply this for v0.12 and after.

With this change, all dagger types will need to be referenced directly from the internal/dagger package. Before:

package main

import (
	"context"
)

type MyModule struct{}

// Returns a container that echoes whatever string argument is provided
func (m *MyModule) ContainerEcho(stringArg string) *Container {
	return dag.Container().From("alpine:latest").WithExec([]string{"echo", stringArg})
}

After (see the change from Container to dagger.Container):

package main

import (
	"context"
	"dagger/my-module/internal/dagger"
)

type MyModule struct{}

// Returns a container that echoes whatever string argument is provided
func (m *MyModule) ContainerEcho(stringArg string) *dagger.Container {
	return dag.Container().From("alpine:latest").WithExec([]string{"echo", stringArg})
}

[helderco]

I support this! It makes it more consistent with the other SDKs, generates less code, and makes the IDE happier because of no hidden docstrings in aliases.

[jedevc]

AH! An issue I wasn't expecting to encounter - there are deps in our dependency tree (see shykes/daggerverse#10), which have random hashes as their engineVersion, which defaults to the latest.

This is fiddly, and not great. For now, we can probably make do by ensuring that our dependencies have good hashes anyways.

But long term, we really need to do #7760 - I'm going to add that to our milestone as well.

[jedevc]

Tests are failing due to dagger/dagger-test-modules#3.

[jedevc]

Hm, one more test is failing, TestModule/TestGoExtendCore - not quite sure why, will dig into this asap tomorrow. Otherwise, is ready for review.

[jedevc]

I pointed https://github.com/vito/daggerverse` to my fork at https://github.com/jedevc/daggerverse-vito, so I could test with #7831.

[helderco]

LGTM!

[vito]

Will be nice to skip the extra hop for go-to-definition, although I guess for that what I'd really want is some sort of magical go-to-backing-implementation feature (instead of the codegen'd client).

Also, I guess you could .-import if you preferred the syntax sugar from before?

Anyway, approving, didn't find anything wonky

[vito]

This bit seems interesting - is it to prevent codegen from blowing up on an unknown type? Maybe because it gets figured out on another pass?

[jedevc]

Yup, that's the behavior in c50cb10 (#7831). It produces invalid code, but the code wouldn't have compiled in the first place - this means dagger develop can at least succeed, so you can actually fix the issues, instead of having to just "guess".

[vito]

I suppose now if I never run dagger develop and the generated module code isn't committed, instead of my editor giving me a bunch of errors for undefined types, there will just be this one unknown import, which is better

[jedevc]

That too I guess! The main reason for this in here is that if you don't do it, go cleverly attempts to "find it" - and often seems to select dagger.io/dagger which is reasonably unhelpful.

[vito]

I think that issue still exists but for dag right? I remember that auto-importing from somewhere. 🤔 Or is that fixed by now too?

[jedevc]

Ah, that issue exists for users if they don't run dagger develop first - since it's in dagger.gen.go. Sadly, I don't know about how to fix that one 🤔