"deployments" could optionally have a name about runway

[ITProKyle]

I think name would make logical sense. Would be nice to see the option to define deployments as a dict using the name as the key as well as supplying the deployments as a list of dicts as shown in your example.

___
deployments:
  - name: global_deployments
    modules:
    ....

OR

___
deployments:
  global_deployments:
    modules:
    ....

[rgitzel]

I'm now thinking that modules should have explicit (and optional) names, as well.

Presumably you could group your module folders in sub-directories, so a module's path might be cfn/whatever and that wouldn't be a great name.

[rgitzel]

@ITProKyle Myself, I prefer maps to lists in YAML, so I like the idea.

But... deployments and modules currently are processed in the order given by the list. If they are read into a dict that ordering would be lost.

[ITProKyle]

@rgitzel

I'm now thinking that modules should have explicit (and optional) names, as well.

Presumably you could group your module folders in sub-directories, so a module's path might be cfn/whatever and that wouldn't be a great name.

I think this is less of an issue then adding names to a deployment. modules already have names since you have to define the path. If the path wouldn't be a good name for the module, then why have the module in that path to begin with?

But... deployments and modules currently are processed in the order given by the list. If they are read into a dict that ordering would be lost.

stacker (a dependency of runway) has logic for handling this that we may be able to reference. the example I provided are both valid formats for defining stacks and *_hooks.

[troyready]

Agreed with the idea of adding the optional name: property to the current deployments presuming its needed for #44 and we move forward with it.

If the path wouldn't be a good name for the module, then why have the module in that path to begin with?
The precedence for this now @ITProKyle is the staticsite modules that allow name: to be specified to override the CFN stack names

[jpoissant]

I would assume that with the PR merged this issue can is not Open anymore. Can we update the issue status?

[GarisonLotus]

@ITProKyle - I think this issue is actually resolved. Can we close the issue out?