#Help using dagger playground to develop a new LLMProvider

1 messages · Page 1 of 1 (latest)

tawdry robin
#

I've been trying to locally try out a new LLMProvider I've attempted to create that wraps GitHub Copilot (GHCP) Cli inside a container built by dagger since there is no REST API or SDK to call GHCP directly.

I've implemented the LLMClient interface (SendQuery and IsRetryable) and returns LLMResponse type to conform to what I can presume/tell is the "convention" from the other LLMProviders [llm_google.go, llm_anthropic.go, llm_openai.go]

I've run as per the docs dagger call playground terminal and I'm a bit stuck/spinning my wheels on what to do next?

I see that the docker engine built from my forked and cloned version of dagger/dagger which has the new llm_github_copilot.go that I wrote and now I wanted to test by writing a new module that can create a new LLM instance and pass the env vars required by the provider I made (most notably export GITHUB_TOKEN="op://dev/ghcp_pat/credentials)

I'm stuck in the sense that I'm not sure what the right workflow would be to develop in this manner - should I write throw away module within the constructed container/terminal instance? Should I some how point my host machine's dagger engine to the one exposed by the built playground at port :1234?

While I could just run/call dagger in the provided container it feels like the wrong way to do it and would prefer to be able to mount a local (on host) module and write in my ide and then run the module via a dagger call??

What's a typical maintainer/contributor workflow past running dagger call playground terminal or should I be locally rebuilding on the host each new update/change to dagger core?

I tried looking up docs, issues and searching in help to see if this has come up and feel like I've missed something as a n00b 🙂

I presume it is a n00b thing but happy to be a lab rat to update docs too for future me when I inevitably forget how to do it correctly.

thanks in advance!

tired abyss
#

for example to mount the current dir + 1password service account token:

dagger call engine-dev playground \
 with-directory --source=. --path=. \
  with-secret-variable --name=OP_SERVICE_ACCOUNT_TOKEN --value=env://OP_SERVICE_ACCOUNT_TOKEN \
 terminal
#

(we temporarily lost the top-level playground function, it's tucked away under engine-dev but I plan on aliasing it back at the top-level)

#

my guess is that when you forked we still had the top-level playground and you haven't rebased on main in the last week or so 🙂 just a heads up

#

you can also use the interactive dagger shell to explore available functions to chain in that way. just call dagger without arguments, you'll get an interactive bash-like interpreter, with autocompletion. dagger functions are mapped to shell commands and you can chain them with |

#

eg.

#!/usr/bin/env dagger

engine-dev |
 playground |
 with-directory . . |
 with-secret-variable OP_SERVICE_ACCOUNT_TOKEN env://OP_SERVICE_ACCOUNT_TOKEN |
 terminal
#

the nice thing about mounting the op service account token specifically, is that it will allow the nested dagger CLI to access your 1p account therefore you can pass all the op:// secret references your heart desires 🙂

tawdry robin
#

makes sense now, thanks @tired abyss

I was getting a head of myself and thinking there would be a way to point the host dagger cli to the playground's version of the built engine (with new provider) so I could do other tests from the host directly with a module that leverages the new bits.

in this way (and what seems like the expected flow) is just mount scripts/modules into the container from another directory/project on the host.

queen bloom
#

in this way (and what seems like the expected flow) is just mount scripts/modules into the container from another directory/project on the host.

correct. this is generally easier since it keeps the environment clean.

there's a ./hack/build script that kind of does what you want which is building both the CLI + Engine and exporting those to your local machine and your docker daemon if that's required for your test. Having said that, we usually recommend sticking to the playground mode since it's more consistent and easier to manage