8000 fix: fix return list type is not slice of pointer of struct by wingyplus · Pull Request #9575 · dagger/dagger · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

fix: fix return list type is not slice of pointer of struct #9575

8000
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

wingyplus
Copy link
Contributor

Fixes #9556

Fix any methods that return list of object must return in form of []*T.

The go template override FormatReturnType to make it works and expose FormatType from common functions type make it accessible from FormatReturnType.

@wingyplus wingyplus requested a review from a team as a code owner February 13, 2025 10:29
Comment on lines +92 to +115
func (funcs goTemplateFuncs) FormatReturnType(f introspection.Field, scopes ...string) (representation string, err error) {
scope := strings.Join(scopes, "")
ff := funcs.CommonFunctions.FormatTypeFuncs.WithScope(scope)

for ref := f.TypeRef; ref != nil; ref = ref.OfType {
switch ref.Kind {
case introspection.TypeKindNonNull:
continue
case introspection.TypeKindList:
defer func() {
representation = ff.FormatKindList(representation)
}()
case introspection.TypeKindObject:
representation = ff.FormatKindObject(representation, ref.Name, funcs.CommonFunctions.ConvertID(f))
representation = "*" + representation
return
default:
return funcs.CommonFunctions.FormatType(ref, scope, funcs.CommonFunctions.ConvertID(f))
}
}
return "", fmt.Errorf("unexpected type kind %s", f.TypeRef.Kind)
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is quite a bit hack. Feel free to suggest if anyone has a better solution. 🙏

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine that way.

A big refactor on how the codegen works will happen at some point and that will be a good time to fix all these small magic tricks.

@wingyplus wingyplus force-pushed the iss-9556 branch 3 times, most recently from d1ed977 to ed4f395 Compare February 17, 2025 12:11
Copy link
Contributor
github-actions bot commented Mar 4, 2025

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

Copy link
Member
@TomChv TomChv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine IMO, just please add a changie notification since it may impacts users.

Comment on lines +92 to +115
func (funcs goTemplateFuncs) FormatReturnType(f introspection.Field, scopes ...string) (representation string, err error) {
scope := strings.Join(scopes, "")
ff := funcs.CommonFunctions.FormatTypeFuncs.WithScope(scope)

for ref := f.TypeRef; ref != nil; ref = ref.OfType {
switch ref.Kind {
case introspection.TypeKindNonNull:
continue
case introspection.TypeKindList:
defer func() {
representation = ff.FormatKindList(representation)
}()
case introspection.TypeKindObject:
representation = ff.FormatKindObject(representation, ref.Name, funcs.CommonFunctions.ConvertID(f))
representation = "*" + representation
return
default:
return funcs.CommonFunctions.FormatType(ref, scope, funcs.CommonFunctions.ConvertID(f))
}
}
return "", fmt.Errorf("unexpected type kind %s", f.TypeRef.Kind)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine that way.

A big refactor on how the codegen works will happen at some point and that will be a good time to fix all these small magic tricks.

@jedevc
Copy link
Member
jedevc commented Mar 17, 2025

Ideally we should version-compat this change - it has the potential to break published modules, so should have a check here.

@wingyplus
Copy link
Contributor Author

Ideally we should version-compat this change - it has the potential to break published modules, so should have a check here.

I’ve never dealing with a version compat before. How to do it?

@jedevc
Copy link
Member
jedevc commented Mar 18, 2025

@wingyplus see https://github.com/dagger/dagger/pull/9118/files#diff-8062ad596c2b352a00e64f30eb9fff7ade878660570bf2c3c5f5aa727dd10496R864 for an example of where I've done this recently.

Generally:

  • If a core function signature changes, you use dagql views
  • If you're just changing behavior somewhere, you can just directly call CheckVersionCompatibility with the Query.

@TomChv
Copy link
Member
TomChv commented Mar 24, 2025

@wingyplus Any news on this PR? I'm ready to approve whenever you address changes :D

@wingyplus
Copy link
Contributor Author
wingyplus commented Mar 25, 2025

@wingyplus see https://github.com/dagger/dagger/pull/9118/files#diff-8062ad596c2b352a00e64f30eb9fff7ade878660570bf2c3c5f5aa727dd10496R864 for an example of where I've done this recently.

Generally:

  • If a core function signature changes, you use dagql views
  • If you're just changing behavior somewhere, you can just directly call CheckVersionCompatibility with the Query.

May I know what scenario I should check here? My understanding is that the codegen binary is built into the dagger engine so it should fallback to previous behavior if we switch the binary back to previous version.

Also, this PR breaks cmd/dagger/module_inspect.go because the initializeClientGeneratorModule function asks for dependencies from the module source via Dependencies(context.Context). It doesn't look like we can use dagql view or check version compatibility to fix this case?

@wingyplus
Copy link
Contributor Author

@wingyplus Any news on this PR? I'm ready to approve whenever you address changes :D

Changelog added. I'm waiting for CI to be complete.

@wingyplus wingyplus force-pushed the iss-9556 branch 4 times, most recently from 6ff2377 to 92e9718 Compare March 31, 2025 19:35
@wingyplus wingyplus requested a review from TomChv March 31, 2025 19:35
Copy link
Contributor

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

Copy link
Contributor
github-actions bot commented May 2, 2025

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@TomChv
Copy link
Member
TomChv commented May 12, 2025

@wingyplus It seems there's not conflict, please regenerate the dagger.gen.go client and then I can review :D

@wingyplus
Copy link
Contributor Author

@wingyplus It seems there's not conflict, please regenerate the dagger.gen.go client and then I can review :D

Will fix in around 2-3 hours

@wingyplus wingyplus force-pushed the iss-9556 branch 3 times, most recently from 6c8668a to 8bd9407 Compare May 15, 2025 23:43
@wingyplus
Copy link
Contributor Author

@TomChv sorry for the delay. I rebased and squashed all the commits. 🙏

Copy link
Contributor
@sipsma sipsma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for tackling the fix for this, I hit it yesterday and was happily surprised to see it was already being worked on. The changes here lgtm.

I agree w/ @jedevc that trying to make this backwards-compatible is important though. The reason being that there's plenty of user module code that will start failing to compile after this is fixed, which is extra bad when it's some external dependency module you as a user don't directly control and thus can't fix yourself.

As painful as it would be, I'd ideally want us to maintain the old behavior for modules w/ older engine versions in their dagger.json. I don't recall if we currently pass that dagger.json engine version information to codegen anywhere, but if we don't I think we could plumb it through to the codegen config (i.e. here) and use that to only have this new behavior for engine versions above the next one.

The code to support both is going to be ugly, but can be cleaned up after there's been enough time for the ecosystem to upgrade. This seems worth it because this fix is for something extremely important that we don't want to be stuck w/ forever.

Fixes dagger#9556

Fix any methods that return list of object must return in form of
`[]*T`.

The go template override `FormatReturnType` to make it works and expose
`FormatType` from common functions type make it accessible from
`FormatReturnType`.

Signed-off-by: Thanabodee Charoenpiriyakij <wingyminus@gmail.com>
@wingyplus
Copy link
Contributor Author

Thanks for tackling the fix for this, I hit it yesterday and was happily surprised to see it was already being worked on. The changes here lgtm.

I agree w/ @jedevc that trying to make this backwards-compatible is important though. The reason being that there's plenty of user module code that will start failing to compile after this is fixed, which is extra bad when it's some external dependency module you as a user don't directly control and thus can't fix yourself.

As painful as it would be, I'd ideally want us to maintain the old behavior for modules w/ older engine versions in their dagger.json. I don't recall if we currently pass that dagger.json engine version information to codegen anywhere, but if we don't I think we could plumb it through to the codegen config (i.e. here) and use that to only have this new behavior for engine versions above the next one.

The code to support both is going to be ugly, but can be cleaned up after there's been enough time for the ecosystem to upgrade. This seems worth it because this fix is for something extremely important that we don't want to be stuck w/ forever.

@sipsma Thank you for the feedback. Let me take a look at the details and will return in around 1-2 days. 🙏

Copy link
Contributor
github-actions bot commented Jun 5, 2025

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

Copy link
Contributor

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

Copy link
Contributor

This PR was closed because it has been stalled for 7 days with no activity.

@github-actions github-actions bot closed this Jun 27, 2025
@wingyplus wingyplus reopened this Jun 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

🐞 Go codegen render return type as value struct instead of pointer struct when a function return a slice
4 participants
0