Contextual modules

[vivid olive]

I almost understand this.

Basically removes the need for a function that exists alongside something else to accept source --path . constantly right? Whilst still allowing for standalone modules intended for shell usage or SDK extension that don't need to be context-aware?

Any chance this could be developed into a hidden poc for an upcoming release, much like the views were?

[tiny bobcat]

@vivid olive I read the issue but my "aha" moment was when I read this comment of yours. Would you mind posting this on the issue itself? And @chrome bear I think adding this to the description as an alternate explanation might help too.

[chrome bear]

sure. which part led to the "aha"? 🙂

[tiny bobcat]

Basically removes the need for a function that exists alongside something else to accept source --path . constantly

The fact that you don't need to pass in source for every cli command (for contextual) is the most useful piece. That piece made sense to me probably because I am an experienced module developer. Probably won't make a difference to a new module dev.

[vivid olive]

The bit I didn't really get was "enclosing directory". If at my project root I have:

package.json
dagger.json
.dagger

Then I'm assuming "enclosing directory" is that project root

[chrome bear]

it's the same mechanism as for a Dockerfile. Except instead of a contextual file (Dockerfile) it's a contextual directory (.dagger).

Also similar to .github

[vivid olive]

The edited issue is much clearer 👍

[chrome bear]

Glad to hear it, thanks for all the feedback

I'm currently replying to all the comments in there. Let me know if the new edited issue still has ambiguity

[chrome bear]

In most cases, your project's root directory would contain a .dagger, and not a dagger.json. (slight change from today)

The exception would be when your project is itself a standalone dagger module. In that case you might have a .dagger (a dagger module to develop your dagger module), and a dagger.json (your own standalone module's configuration)

This solves another problem, which is that there's no clear way to have CI for your own standalone dagger modules. This clarifies how to do it: just add a contextual module inside your module, with functions needed to develop that module

[vivid olive]

So you intend the CLI to treat a .dagger dir the same way it currently treats dagger.json, so the module's context dir is just automatically the application's root dir?

[chrome bear]

It wouldn't work exactly the same (a context dir is different from a module root dir), but it would solve some of the same problems.

In other words, today the alternative to creating a contextual module, is to make your application itself a module. You wouldn't need to do this anymore.

[tiny bobcat]

Will that allow me to run dagger call functions from the root of my source code without specifying the module name? Or would that still required me to convert my own code into a module?

For example, if I have a cidirectory. From my project root can I call dagger call functions (given ci is a singular module). Or do I do dagger call -m ci functions

[chrome bear]

yes that will work without explicit -m. That's the main purpose of the "indirect loading"