Why is AddSecret not available anymore

[cloud tinsel]

It's still available, if you've pulled latest main then you won't get an autogenerated method for it anymore when running cloak generate. But the method still exists and works the same

I can send you an example using the raw client, one sec

[coral wraith]

It means I need to implement the GQL query request/response by myself?

I know it seems it has been changed 2 h ago, but my pull is from earlier yesterday

But yeah, I'm open for any example

[cloud tinsel]

https://github.com/dagger/cloak/blob/728513410adf6f6518c816edd857e76c0497726e/internal/testutil/query.go#L47-L68

If you haven't pulled in the last 2h then nothing should have changed

[coral wraith]

I just have core.Secret()

[cloud tinsel]

There was AddSecret in the operations too (since 4 days ago), so I'm not sure why you wouldn't have it in the autogenerated methods

But either way, I'd just use the raw query interface for now

[coral wraith]

Hmmm

maybe because I hade some generated files already

it didn't overwrite the already generated files

let's try again

[cloud tinsel]

The client generated files are (well, "were" now) overwritten, so not sure

[coral wraith]

I removed all the gen files, and now I got: Error: failed to solve: no queries found, looked in: /home/dolanor/src/cloak/examples/hugo/gen/alpine/operations.graphql (configure this in genqlient.yaml)

[cloud tinsel]

Yeah I'm guessing you have a dependency on the latest main branch for alpine in your cloak.yaml

That alpine no longer has operations defined (part of the change 2 hours ago)

So now you'll need to update to the newest cloak

or I suppose you can specify the older commit instead of main

[coral wraith]

oh, I see

[cloud tinsel]

But I'd suggest switching over to the raw sdk

I'm happy to help out if needed, I realize this is incredibly annoying

It's just pain we wanted to get over with now

[coral wraith]

so the raw sdk would be the testutil.addSecrets func you showed me before ?

[cloud tinsel]

Yeah, I don't know why I used the term "raw sdk", I mean the raw graphql client. The func I sent before is an example of using raw queries

[coral wraith]

ok

I pulled main + rebased, still same error.

#1 local://__cloak_workdir
#1 transferring __cloak_workdir:
#1 transferring __cloak_workdir: 12.92kB 0.0s done
#1 DONE 0.0s

#2 copy / /
#2 DONE 0.0s

#3 git://github.com/dagger/cloak.git#main
#3 1.330 728513410adf6f6518c816edd857e76c0497726e    refs/heads/main
#3 DONE 1.4s

#3 git://github.com/dagger/cloak.git#main
#3 CACHED
Error: failed to solve: no queries found, looked in: /home/dolanor/src/cloak/examples/hugo/gen/alpine/operations.graphql (configure this in genqlient.yaml)

Thanks for the support btw, that helps

wait

didn't rebuild cloak

better!

But, does it mean I need to reimplement the core.Exec myself with the raw queries?

[cloud tinsel]

For now yes, it also means you can do more chaining in the query itself so there is room to save lines of code in some cases too

[coral wraith]

Ok

I guess I have to let go for now, sorry @frosty coyote , couldn't make it. Gonna go to bed now.
Thanks Erik for the support, really!

[cloud tinsel]

Glad to help! Let me know as stuff comes up or if I can help more

[coral wraith]

Finally it's nagging me.
Why was core generated before? It seems the code is generic enough that it wouldn't be needed specialization, right?

[cloud tinsel]

The long-term goal is that you should be able to use all the APIs (both core and other extensions) from the language you know (i.e. go) in a completely "native" and intuitive way. Being forced to learn graphql and then write those raw queries diverges from that goal. In go in particular, it's really tedious and annoying and you also lose compile time type safety.

So we started w/ using the 3rd party client codegen tool (genqlient). It technically works but has a ton of huge caveats like that issue you and others ran into where there's multiple FSIDs that can be returned, but only one is the right one

[coral wraith]

yep

[cloud tinsel]

What we eventually want is a codegen approach that retains type safety, feels "natural" in each language but also lets you build+chain queries flexibly. That's going to require our own query-builder tool

[coral wraith]

But at least for Go, as we already have a cloak/core, couldn't we implement those func in there and use it from the extension/scripts?

[cloud tinsel]

Totally possible, but given the enormous number of high priorities, we have to work on other things at the moment

[cloud tinsel]

Ah I see, yeah I was thinking about that too as some possible short term pain relief

[coral wraith]

Oh, I understand now

[cloud tinsel]

It would make the very simple cases more straightforward. But it would also discourage use of custom chained queries, which I think is one of the pros of the new raw query builder. It also requires manually keeping those hand-written wrappers in sync with the schema. Totally possible, but extra maintanence cost

[coral wraith]

I guess since you used genqlient, even if it generated the same code for different extensions, since it was generated based on your *.graphql files, it was more logical to vendor it alongside the extension

[cloud tinsel]

Yep that too. It was just easier to treat core the same way we treated all the other user extensions too. Having a way to add a dependency on the cloak repo and get clients generated from the schema but also a way to generate clients based on the version of your cloak binary just gets really confusing, better to only have one path

(I gotta go to bed, talk more tomorrow!)