People will probably want some kind of output wiring

[spilliams]

not unlike Terragrunt's dependency blocks. maybe use terraform_remote_state blocks though.

[spilliams]

It strikes me that the program currently does not care where state is stored for a given root. In order to provide a downstream root with a remote state data source on its dependency, it will need to know where the dependency stores its state. Which means we'll need a backend block in terrascope.

This feels too heavy. How about this: for this ticket to be called Done, implement an example that uses a dependency and internally has a remote state block that pulls on some of the root scope variables to configure that data source.

[spilliams]

The remote_state option is interesting, but I think out of scope for this entire project.
Until and unless terrascope knows about a root-scope's backend, we can't have it tell downstreams those details.

There are two options I see, not mutually exclusive:

1. terrascope provides, in the context, all of the attributes of each dependency. Users could build a module that would take attributes and build a remote state. This is something I could provide an example of. Perhaps the user could build a "partial" of a module.(Have I done anything with partials yet? I meant to...)
2. terrascope provides, in the context, the terraform output from each dependency. This should be flagged so that the user can tell terrascope to do it or to not do it. It must not happen 100% of the time. I can't tell which direction it should be flagged though.

If we implement both options, the context (and thus the debuggable context file) would look like this:

root = {...}
scope = {...}
attributes = {...}
dependencies = {
  foo = {
    attributes = {...}
    output = {...}
  }
}

[spilliams]

(No, I haven't done anything with partials yet. I do have a generate block in the root schema, which works for now. But maybe I'll want partials...)

[spilliams]

AC for this is the 2nd point above.

1. Build a flag in the root dependency schema that tells terrascope to include (or exclude) the dependency's outputs.
2. when the flag is enabled (or disabled), provide each dependency's outputs as part of the context of the root-scope.

[spilliams]

ooh, maybe the project has a default, and the root can have a flag that overrides that setting. I like that.