Unify language handling for multi-impl-lang test suites
Feature request summary
Currently we have a metadata structure which requires that any given Subplot document provide scenarios only for one implementation language. For example, the main subplot.md
only tests via a Python implementation.
Sometimes this makes perfect sense, for example, testing daemon
which is a library (currently) only available in the Python backend. Other times, it's a problem, for example with the datadir
, files
, and runcmd
tests which are all available in multiple backends, leading to multiple copies of the file which risk getting out of sync.
Example usage
The first step would be to change the frontmatter metadata format from:
template: $lang
files:
- a.$lang
- b.$lang
to:
impl:
$lang1:
- a.$lang1
- b.$lang1
$lang2:
- a.$lang2
- b.$lang2
This would (a) still mean if you have only one implementation language listed you have a default, but (b) that if there is more than one listed in a document, we need to know which to pick in codegen - subplot codegen -t $lang foo.md -o whatever.$lang
In order for this to make sense, we would change bindings so that they support multiple languages - this inherently also deduplicate the binding work and makes it safer for us to alter library bindings in a way that won't get out of sync between langauges...
- given: file {filename_on_disk} from {embedded_file}
types:
embedded_file: file
filename_on_disk: word
function:
rust: subplotlib::steplibrary::files::create_from_embedded_with_other_name
python: files_create_from_embedded_with_other_name
or an example from subplot.yaml
- given: an installed subplot
function:
python: install_subplot
rust: install_subplot
cleanup:
python: uninstall_subplot
rust: uninstall_subplot
The intent here is that we won't have to duplicate bindings across langauge templates, but that we can have different function names in each language template without issue. It would be possible to statically check that for the set of template langauges a document opines interest in, that the bindings used by that document all have support for that template language. As such if there were a given the python interpreter is new enough
binding which was only relevant for python, you could still use the binding file it was in as part of a document which was to target Rust, so long as it didn't use that binding in one of its scenarios.
Further quality-of-life things
The subplot metadata
output should contain the list of template languages the document supports. This should be easily processed by scripting which might want to generate multiple tests (e.g. our ./check
will want to verify test suites in both Rust and Python most likely).