exo

exo copied to clipboard

It's natural for some components to have customization points or other forms of dynamic configuration. A typical solution is to support environment variables (see #78) and/or some form of templating.

Components have props, which are (disjointly?) partitioned in to spec and state. Spec properties are expression-like and state properties are promise-like. That is, spec may be defined in terms of other properties and variables, where as state is asynchronous observations of resources.

Prior art here:

• procfiles are interpreted by your shell, allowing arbitrary substitution.
• docker-compose has variable interpolation: https://github.com/compose-spec/compose-spec/blob/master/spec.md#interpolation – this implements the safe environment variable subset of shell substitution syntax
• kubernetes et al use Go templates

See also #78 regarding environment variables

Assigning this to myself as part of the manifest work. Manifests are HCL formatted and so there is an expression language.

+1, at present env CONTAINER_VERSION=dev exo apply docker-compose.yaml will produce something along the lines of Error response from daemon: no such image foo:: rather than resolving the environment as docker-compose will.