You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 9, 2020. It is now read-only.
There have been advancements in the schema-salad to generate Python classes that more directly mirror the functionality this project provides. As a consequence, it's probably worth investigating migrating some of the generator tests to the new repo and deprecating this project.
I've used the grammar from common-workflow-language/cwl-utils#5 for these initial tests. From migrating some of the cwlgen tests, I've noticed some differences:
Identifiers and derived fields are based on the file path are different (for the tests test_unit_import_workflow):
Current cwlgen identifier = 1stWorkflow
New cwl-utils identifier = file:///path/to/import_workflow.cwl#1stWorkflow
This affects identifier derived fields, including: format, source, run.
Some method similarities (cwlgen → cwl-utils):
get_dict() → save()
parse_cwl(cwlfile) → load_document(cwlfile)
parse_dict → No super clear analogue, but loaded through _RecordLoader(CommandLineTool) || _UnionLoader((CommandLineToolLoader, ...workflow + other loaders)
Additionally, to avoid conflicting with Python keywords we made some specific keyword changes when creating cwlgen, here's how some at least might be mapped back on the initialiser.
tool_id | workflow_id | input_id | etc→id`
StepInput: inputs→in_`
Other little differences (more investigation required):
Update 2020-06-01 - This has been resolved and will be released in cwl-utils 0.4
After save(), requirements is a `List[CommentedMap] == ordereddict[] which I don't know how to unit test..
Update 2020-06-01 - Most dict comparisons just work.
The big difference is that any issues can be solved by regenerating the file based on the schema-salad definition of CWL, so it should always be right. When I get a chance, and once optional init fields are in schema-salad I'd be interested in migrating a real world project to using it.
There have been advancements in the schema-salad to generate Python classes that more directly mirror the functionality this project provides. As a consequence, it's probably worth investigating migrating some of the generator tests to the new repo and deprecating this project.
I've used the grammar from common-workflow-language/cwl-utils#5 for these initial tests. From migrating some of the cwlgen tests, I've noticed some differences:
Identifiers and derived fields are based on the file path are different (for the tests
test_unit_import_workflow):1stWorkflowfile:///path/to/import_workflow.cwl#1stWorkflowformat,source,run.Some method similarities (cwlgen → cwl-utils):
get_dict() → save()parse_cwl(cwlfile)→load_document(cwlfile)parse_dict→ No super clear analogue, but loaded through_RecordLoader(CommandLineTool)||_UnionLoader((CommandLineToolLoader, ...workflow + other loaders)Additionally, to avoid conflicting with Python keywords we made some specific keyword changes when creating cwlgen, here's how some at least might be mapped back on the initialiser.
tool_id |workflow_id | input_id | etc→id`StepInput: inputs→in_`Other little differences (more investigation required):
Optional fields don't default toNoneon init_, which means you'd always have to include them. Refer to --codegen python: have normal __init__ , add method for parsing from a doc common-workflow-language/schema_salad#262 for more information.save(), requirements is a `List[CommentedMap] == ordereddict[] which I don't know how to unit test..The big difference is that any issues can be solved by regenerating the file based on the schema-salad definition of
CWL, so it should always be right. When I get a chance, and once optional init fields are in schema-salad I'd be interested in migrating a real world project to using it.FYI @mr-c