Open traut opened 1 month ago
an alternative namespacing schema that does not break HCL identifier constraint is to use --
as a separator:
document "my-doc" {
section ref {
base = fabric_templates--section.ctid_executive_summary
}
}
However, it is less "namespacy" -- the prefix is not perceived as a namespace at a glance.
@traut
What about separating namespace with prefix import.<plugin>.<path>
? Usage:
document "my-doc" {
section ref {
base = import.fabric_templates.section.ctid_executive_summary
}
We could also choose different prefix like template.<plugin>.<path>
or plugin.<plugin>.<path>
@dobarx oh, that's neat! I like import.<plugin-name>.<path>
a lot, awesome idea!
It is clear that it is an import while the name is nicely namespaced. Let's go with it!
One thing that occurred to me:
We talked about adding a manifest-like to the plugins. Another argument and use case for it, in the context of template distribution in the plugins, is the need to have a list of template dependencies -- what plugins must be installed for the templates to work?
Background
With the content libraries, like Fabric Templates, accumulating useful templates for various use cases, and vendors producing integration-specific templates, there should be an easy way for the users to access the templates.
Design
Utilize our existing plugin infrastructure (plugin registry and dependency installation logic) to deliver content by including the templates inside the plugins.
Requirements
blackstork/elastic
pluginblackstork/fabric-templates
plugin that would represent Fabric Template release.ref
syntax:section.ctid_executive_summary
) without breaking the parsing, we should do it. If it would require significant refactoring or breaking changes, we should postpone it.blackstork/fabric_tempaltes
plugin would look like this:Full example:
Implementation
TBD in the comments
Constraints
fabric
execution instead of unpacking-on-the-fly