-
Notifications
You must be signed in to change notification settings - Fork 5
Description
๐ฎ Relevant Command
importer update, importer generate, importer graph, importer preview
๐ Language Type
All
๐ Request Details
Goal
Support variable interpolation of some sort, so that the same Exporter Marker can be tweaked only slightly at the Import time.
Background
When I originally started implementing Importer, I wanted to keep the use case as simple as possible. Variable handling was definitely going to add more complex code to support it, and getting the Importer Marker simple enough to learn and support was not so easy to get right. But as we use Importer more and more in the actual configurations, it became evident that some form of variable support will make the Importer usage much easier and more streamlined, and much more "Marker" reuse can be achieved.
Possible Solutions
There are a few scenarios to be supported.
Interpolation with Exporter Marker
When an Exporter Marker has variable interpolation template, when Importer Marker refers to it, it can supply a variable value to it. This assumes the following:
- Importer Marker needs to specify the Exporter Marker and variable input. When the variable value is missing, Importer actions will fail and report an error about missing variable.
- Exporter Marker can specify default value when the variable input is missing. In a case when Importer Marker does not specify the variable, Importer actions will report a warning about the default variable being used. In order to suppress such a warning, Importer Marker can specify to use the default variable.
- From the Importer Marker perspective, variable values should be something that can be defined globally. Instead of providing the variable each time along with Importer Marker, we can support some configuration file such as
importer.config.yaml/importer.config.toml, where all variable values can be defined in one place.
Variable data swapping
Rather than having an Exporter Marker for everything, it would be great to support importing "variable" only. This is challenging in language where partial in-line comment is not supported, such as YAML, because swapping once is easy but there has to be some note how the variable has been swapped.
One possible approach is to copy the original line as comment, and update the variable in another line. This approach is explicit, and the variable name change will be tracked correctly.
Another approach is to update the Importer Marker so that it keeps track of the original variable name as well as the swapped value. This approach allows simpler syntax, while ensuring the variable update can be managed by swapping either variable placeholder, or the actual value being used for the swap. This approach is however less safe, especially when the swapped data is updated manually outside of Importer control, and also when the same data appears more than once in the line.
Considerations
This does add extra complexity. But because Importer only updates the file in-place, so any additional logic is often easy to see from "importing" usages.
The more concerning item is the Marker syntaxes, and additional configuration file handling. Importer did not need any configuration file, but having a configuration file means there is an additional input that is not always easy to see (especially if the configuration file needs to be looked up in each parent directories).
At the very least, we will need the following commands to support:
- Get the config file that will be used by Importer, such as
importer config current - Allow swapping configuration, such as
importer --config x.config.yaml - Create new config file template, such as
importer config new - Add verbose logging when configuration file is being used, such as
importer --verbose, which would write to stdout which configuration file is being read, and what variables are defined, etc.