#CWD module headaches

1 messages · Page 1 of 1 (latest)

restive bay
#

🧵

#

<@&946480760016207902>

#

@brisk ibex we're at iteration 2 of the solution, I'm considering iteration 3...

#
  • Iteration 1: CWD module works like -m. It's always loaded - and it tramples .dagger/config.toml. This is bad because it means a module will always check itself -> bad
#
  • Iteration 2: CWD module is a fallback when no .dagger/config.toml is found. This is a balance: out of the box it is backwards compatible (cd my/module && dagger call foo works like before). But you can drop .dagger/config.toml and then CWD module is neutralized (module stops checking itself unless you explicitly want it to)
#

I'm now considering iteration 3: CWD module is never loaded (remove the feature). If you want to load your module, load it: dagger -m .. Yes we lose backwards compat, but it wouldn't be the only breaking UX change in this branch - and it's one less subtlety for users to worry about

#

In any case (iteration 2 or 3) you shouldn't need a special handling in Cloud. We also want dagger check in a module repo to work cleanly with or without cloud

#

wdyt @brisk ibex @ionic jewel ?

brisk ibex
#

I'm in favor of 3. I think the behavior of 2 would cause more unexpected surprises than 3

restive bay
#

Yeah agree

#

We can't sweep the workspace -> module change under the rug anyway... So we know we can't make things perfectly transparent. Better to make the change as logical and easy to grok as possible

#

TLDR what to do with dagger module init, dagger module install, dagger develop, which stick out like a sore thumb in workspace - ie all the builtin commands related to module development

#

Based on discussion with @hexed isle today, it might make most sense to rip off the bandaid and just delete them - and replace them with: dagger install github.com/dagger/go-sdk or whatever your SDK Is

#
  1. Setup workspace for developing a module. Before: nothing. After: dagger install MYSDK
  2. Initialize a new module. Before: dagger init --sdk=MYSDK. After: dagger call MYSDK init
  3. Re-generate a module. Before: dagger develop. After: dagger generate
  4. Update runtime dependencies. Before: dagger update. After: 🤷‍♂️
#

In the context of dedicated module repo - the topic of this thread - we could adapt compat mode & migrate to detect any dagger.json, and transform that into a workspace config with the right sdk installed

brisk ibex
#

Yeah I could get onboard with that

restive bay
#

main downside is: even larger scope on workspace before merge 😬

hexed isle
#

One very cool thing with dagger call MYSDK init is each SDK become fully responsible of it, and can also add any kind of flags that are a bit harder to add right now. For instance we can imagine something like dagger call typescript-sdk init --runtime=bun or dagger call java-sdk init --builder=gradle --java-version=23 etc.
The init become a convention more that an actual contract, with more flexibility.
And of course it become possible to do something like dagger call MYSDK init --name=test and it will create it in .dagger/modules/test or dagger call MYSDK init --name=foo --path=my-modules/bar

Update could be the same: dagger call MYSDK update [--path=...] (if no --path it can for instance loop on all the modules handled by the MYSDK). But I'm seeing two issues/questions:

  • how to update all modules if the update function is defined in each SDK?
  • update and init have both a first phase that is not specific to the SDK: writing or editing the dagger.json. Then it might do some calls like creating the template, and both should ended up by running the generate function to create/update bindings and entrypoint. So the question here is how to make the edition of the dagger.json shared across all SDKs. Maybe that should be some kind of internal feature exposed by the engine? But it means each SDK should replicate the same update function, with the same arguments, etc. If not it will be a mess.