Package sources and conflicting file names for raw templates

[kddejong]

In the following scenario you would end up with two VPC stacks. Is there way to force a certain raw package to be used when defining template_path?

package_sources:
  git:
    - uri: [email protected]:SomeUser/vpc.git
    - uri: [email protected]:SomeUser/config.git

stacks:
  - name: vpc
    template_path: cloudformation.yaml
  - name: config
    template_path: cloudformation.yaml

[kddejong]

I would add I tried to work around this a little bit by using a master git repo with git submodules but it doesn't look like the clone handles submodules

[phobologic]

@troyready any comments on this? I haven't dug into the package_sources stuff in a while.

[troyready]

Unhelpful background to start: the template_path is modeled after the class_path behavior: first one matching/found is used. If the paths aren't specific enough in either scenario, it'll be unpredictable and not great.

Since python packages are a little more particular in directory traversal (if the first matching directory in sys.path matches the directory specified for class_path, then it won't fall back to other directories if that first directory doesn't have the expected module), I just recommend making the paths more specific.

[kddejong]

I was kind of thinking that would be the response but wanted to ask anyways.

I was hoping for one of two solutions. One was where I could specify the package source when specifying the template name the other would be an error when duplicates are found.

The scenario I am thinking of is when we build out an AWS account I may have 10-15 templates that are used to setup all the different components, networks, security, roles, etc. If someone adds a new repo with a template name that matches another then we could have some disastrous results.

While I haven't tried if I could do a pre-build step to verify this myself. As long as pre-build runs after the packages are collected.

[troyready]

A colleague of mine had similar designs to associate the template_path (or class_path) with a particular package_source. Some sort of metadata on the package_source that could be referenced in the stacks/hooks.

I chose not to implement it for the current template_path option for simplicity (and fear of adding yet_another_config_option), but wouldn't be opposed to having it.

For now, because you can store templates in subdirectories (and further restrict what templates are searched using the paths option, I think it's possible to be specific enough to make the template sourcing predictable.

[phobologic]

Ok, changed the labels in case this is a feature that someone wants to take on. Thanks @troyready !