Currently, the ODK is actually three completely different things:
a standard toolbox;
a standard repository layout;
a standard set of workflows.
While the latter two go quite naturally together (the workflows assume a given repository layout, so they need to be kept in sync), I think the toolbox at least should be separate from the rest.
The ODK could be broken down in two (or maybe three) components:
1) The toolbox, which would still take the form of a Docker image.
2) A templating tool, which would create (“seed“, in ODK parlance) a new repository or update an existing one – this would include the creation/update of the Makefile that implements the standard workflows.
The ”templating tool” could simply be the existing odk.py script and the associated Jinja templates, but packaged as a distinct project instead of being maintained in the same repository as the ODK toolbox. The toolbox would include it, but it would also be possible to use it on its own, without requiring the toolbox at all.
Alternatively, the “templating tool” could possibly be built on top of existing templating systems. For example, maybe a CookieCutter template could be enough? But that would probably mean that existing $(ONT)-odk.yaml configuration files could not be used, so not sure whether this is a good idea.
A third component that could be maintained separately is the src/ontology/run.sh script, which is becoming more and more complicated (and whose feature are partially duplicated in seed-via-docker.sh; also, the Windows variant is systematically left behind). I envision some kind of odk-runner tool that would transparently run commands using whatever “toolbox backend” is available on the system (e.g. using natively installed tools when present, or Docker, or Singularity).
Currently, the ODK is actually three completely different things:
While the latter two go quite naturally together (the workflows assume a given repository layout, so they need to be kept in sync), I think the toolbox at least should be separate from the rest.
The ODK could be broken down in two (or maybe three) components:
1) The toolbox, which would still take the form of a Docker image.
2) A templating tool, which would create (“seed“, in ODK parlance) a new repository or update an existing one – this would include the creation/update of the Makefile that implements the standard workflows.
The ”templating tool” could simply be the existing
odk.pyscript and the associated Jinja templates, but packaged as a distinct project instead of being maintained in the same repository as the ODK toolbox. The toolbox would include it, but it would also be possible to use it on its own, without requiring the toolbox at all.Alternatively, the “templating tool” could possibly be built on top of existing templating systems. For example, maybe a CookieCutter template could be enough? But that would probably mean that existing
$(ONT)-odk.yamlconfiguration files could not be used, so not sure whether this is a good idea.A third component that could be maintained separately is the
src/ontology/run.shscript, which is becoming more and more complicated (and whose feature are partially duplicated inseed-via-docker.sh; also, the Windows variant is systematically left behind). I envision some kind ofodk-runnertool that would transparently run commands using whatever “toolbox backend” is available on the system (e.g. using natively installed tools when present, or Docker, or Singularity).