#@Kyle Penfound @vito I ran into a
nocturne tapir
It has to do with generated clients in test code..
Combined with loading local modules from the workspace
Basically when loading a module from elsewhere in the workspace, all the module files must be present in the client filesystem. In the context of an e2e test file, that client filesystem is a container running inside dagger. So, it doesn't contain the whole workspace, unless you explicitly include the files you need. So if my e2e test needs to import module ../toolchains/cli-dev, which in turn needs ../toolchains/engine-dev, then all the files needed to load both modules must be explicitly included by me.
Instead, need a way to load local modules from the workspace API. My test code can already access any file it needs in the workspace, with dag.CurrentWorkspace().File(...). Why not also load modules? Not sure what the API for that should be (and how to handle codegen for it). But that's what I need....
@rugged nacelle @reef tartan
reef tartan
In theory we could have dag.CurrentWorkspace().Module("xxx").Load() ?
So you can dynamically load a module from the engine side, so that removes a bunch of issues in the generated client
nocturne tapir
@rugged nacelle since you're working on self-calls -> any thoughts on this?
The context is: native tests loading local modules in the workspace
rugged nacelle
example: https://github.com/dagger/dagger/pull/13032/changes#diff-1a8fcd4c79c02e...
Just to be sure to understand, the issue is the need to write all those // workspace:include so that the dag.DaggerCli() can succeed, right?
nocturne tapir
Just to be sure to understand, the issue is the need to write all those `// work...
Yes, and not just for loading the Cli module, but also all the other files it might need; and all the files to load its transitive dependencies, too
Maybe it's as simple as: when a client calls dag.ModuleSource(), the engine honors the client's current workspace when loading local modules, instead of literally the client's filesystem.