Dear CWL community,
at Terradue, an Earth Science company, we strongly rely on CWL as part of the foundation of our Earth Observation data processing platform and, aside the well known and estabilished cwltool, we had the need to develop some side-tools to assist our staff and partners during the development lifecycle.We also identified the Workflows design as a strategic part of our daily job to make the CWL adoption clear to Python developers who are not familiar with CWL, this is why I’d like to share a small tool we’ve been working on: cwl2click.
It helps you turn CWL CommandLineTool descriptions into a ready-to-use Python CLI built with click, so you can quickly expose a CWL tool as a friendly command-line interface (with help text, options/arguments, and sensible defaults derived from the CWL definition).You can easily find references on GitHub:
Fast prototyping: get a working CLI without hand-writing argument parsing.
Consistency: keep parameters, defaults, and documentation anchored in the CWL spec.
Lower friction for users: a familiar --help-driven interface for colleagues who aren’t editing CWL day-to-day.
If you have a CWL CommandLineTool lying around, I’d love if you could try cwl2click, see how it behaves with your inputs/requirements, and share feedback:
Does the generated CLI match your expectations?
Any CWL features you’d like to see supported next?
Any rough edges in UX, naming, types, defaults, or documentation output?
Thanks in advance to anyone willing to test-drive it and help improve it.
Best regards,
I might have some time in January / February as I am writing some docs for a project with CWL. In my case I’m interested about CWL + MPI producing some provenance files. I can probably find some CWL command line tool and give it a try with cwl2click over next days.
By the way, Simone, is that you (from Apache)? If so, good to see you around here and working with workflows + CWL + Earth Sciences!
I sent some feedback via GitHub, Simone. One pull request and two issues. We can discuss more there about those issues. After reading the docs and doing some tests, the only question I have is if I understood the use case correctly.
As I use cwltool with my workflows/tools, and it already provides a CLI with --help, I think I wouldn’t need to use cwl2click. But if I were to use it in an existing project, especially if it already uses Click, then cwl2click could be useful. Or if I am using a CWL implementation that doesn’t provide the CLI for my tool?
I guess some users may prefer a utility instead of calling cwltool or another implementation runner, plus passing the CWL file. But that could be solved with an alias or a small wrapper script too that calls cwltool/etc., I think?
Thank you so much for your kind interest in our small tool an please apologies for the late reply!
Let me try to rephrase, to better illustrate our use cases: we adopted the CWL as the single source of knowledge of the contract-first development approach and we design the whole “big picture” around the CWL document; so, cwl2click makes sense where:
The CommandLineTool(s) you need to develop do(es) not exist yet;
CommandLineTool(s) need(s) a contract, in order to be integrated in the Workflow;
You need to save time and speed up the CommandLineTool(s) development.
This is where cwl2click fits better and we didn’t take in consideration any other usage (yet!).
OTOH, when we are in the case where there’s the need to integrate existing Python application(s) developed with Click into CommandLineTool(s) to CWL, we previously designed an “inverted” tool called click2cwl.
I hope this brief resume helps to clarify our intentions.
Many thanks for the PR, really appreciated, I am going to review it right now!
Looking forward to chat with you soon, all the best!
