Accessing builtin modules

[ripe roost]

Technically yes, but it's big PITA. You can use Host._builtinContainer but you need to provide the SHA of the container. The engine knows that because we set it an an env var when we build the engine container. The sources are included in the container

it was only meant for internal consumption really, hence the _ prefix

That also stops it from even being part of the generated sdk code, have to use raw gql queries

[modest reef]

OK thanks. Long story short, I'm going to try ejecting all module development commands from the main dagger CLI, into nice user-facing SDK modules. So you can eg dagger install go-sdk, then dagger call go-sdk mod init --name=mymodule --template=quickstart or whatever

Then dagger generate to re-generate the module code etc

But, since that cute user-friendly go-sdk module doesn't actually exist, and we can't install the raw sdk runtime module (not meant to be shown to end user directly), I'm going to try adding a facade -> you install a sdk runtime, the engine shows you a user-friendly facade for it

So, it's the facade that would be calling those builtin runtime modules in the backend. Therefore ugly hacks that involve embedding hashes etc are not an issue

[modest reef]

@ripe roost does this look like the right shape? https://github.com/dagger/dagger/pull/13136

TLDR:

• dagger core module-source --ref-string=python-runtime as-module
• dagger core builtin-module-source --ref-string=python-runtime as-module

[ripe roost]

just took a quick look and yes looks directionally good

[modest reef]

Accessing builtin modules