adapters allow you to use divvy with any source of variables.
divvy originally was part of looper. therefore, the default divvy variables (like {CODE}, etc) are from looper. removing divvy from looper decoupled the software, but the variables are still tightly coupled. To make it more flexible, we need to remove this coupling. divvy adapters do that.
here's a config file with adapters:
adapters:
code: looper.command
logfile: looper.logfile
jobname: looper.jobname
cores: compute.cores
time: compute.time
mem: compute.mem
docker_args: compute.docker_args
docker_image: compute.docker_image
singluarity_image: compute.singularity_image
singularity_args: compute.singularity_args
compute_packages:
default:
submission_template: submit_templates/localhost_template.sub
submission_command: sh
local:
submission_template: submit_templates/localhost_template.sub
submission_command: sh
adapters:
custom: custom_adapter_here
slurm:
submission_template: submit_templates/slurm_template.sub
submission_command: sbatch
singularity:
submission_template: submit_templates/localhost_singularity_template.sub
submission_command: sh
singularity_args: ""
singularity_slurm:
submission_template: submit_templates/slurm_singularity_template.sub
submission_command: sbatch
singularity_args: ""
adapters are simple variable mappings from one name to another. they can just be straight-up var:var mappings, but they can also include namespaces (on the supply side; divvy variables aren't namespaced).
This system would allow us to include a 'divvy-looper' adapter. this adapter could be modified either for a universal divvy config, or for a particular compute package, which would enable divvy templates to be used with multiple variable sources.
under this system, looper would simply provide to divvy all available namespaces, the same as it does for command templates. the adapter would convert these into the divvy variables. the advantages is now divvy templates are useful beyond looper. it also simplifies what looper has to do: nothing.
divvy should ship with looper adapters, something like the above example.
what do you think @stolarczyk ?
adapters allow you to use divvy with any source of variables.
divvy originally was part of looper. therefore, the default divvy variables (like
{CODE}, etc) are from looper. removing divvy from looper decoupled the software, but the variables are still tightly coupled. To make it more flexible, we need to remove this coupling. divvy adapters do that.here's a config file with adapters:
adapters are simple variable mappings from one name to another. they can just be straight-up var:var mappings, but they can also include namespaces (on the supply side; divvy variables aren't namespaced).
This system would allow us to include a 'divvy-looper' adapter. this adapter could be modified either for a universal divvy config, or for a particular compute package, which would enable divvy templates to be used with multiple variable sources.
under this system, looper would simply provide to divvy all available namespaces, the same as it does for command templates. the adapter would convert these into the divvy variables. the advantages is now divvy templates are useful beyond looper. it also simplifies what looper has to do: nothing.
divvy should ship with looper adapters, something like the above example.
what do you think @stolarczyk ?