For restricting a particular value (like a string or a number) to a subset there is a proposal under development at common-workflow-language/common-workflow-language#764
@yangchoo Maybe you could join our next weekly video chat and introduce your project and we can discuss further?
@yangchoo Here are the notes from this week's call which has the time and date for the next meeting https://docs.google.com/document/d/1p9Ielg_Icxd2Nlyw5qReFXPn9LrrxgdhlVcs7_dwrf0/edit
2020-07-14 14:30 UTC
I am currently trying to get some javascript working in cwl and I am working under cwlVersion: v1.2.0-dev3 but some mapping is not accepted due to a version issue: cwls/assembly/spades_test.cwl:19:9: JSHINT: W119: 'arrow function syntax (=>)' is only available in ES6. CWL only supports ES5.1
is there a way to enable this support?
I noticed this issue: common-workflow-language/common-workflow-language#329 which is already open since 2016 but i was wondering if there is already any support?
we are trying to fix https://github.com/common-workflow-library/bio-cwl-tools/blob/release/spades/spades.cwl -- thinking EcmaScript 6 that generates yaml might be a bit better than ecmascript 5.1 that generates a shells script that generates a shell script that runs a Python script
somebody just needs to do the work
so a use could add requirements: {JavascriptVersionRequirement: {jsVersion: 6}}
the file declares its version so the runner is supposed to run it as that version
but you can also have a v1.1 workflow that includes v1.0 tools or the other way around (v1.0 workflow and v1.1 tools)
and then for the v1.x series in most cases you can trivially change the number from v1.0 to v1.1 to v1.2 etc and it'll still be valid
but v2.0 will likely have syntax-breaking changes so being able to run v1.0 from a v2.0 workflow would still work (as separate files), but being able to trivially change the version number on the file from v1.0 to v2.0 might not
Ok, thank you for clarifying! A goal of the organization I'm in is to have robust, reproducible, and portable bioinformatics tools and pipelines. We use Docker, and have begun to build our own tool-specific Docker images, as opposed to relying upon those made by others. CWL is the other component of that, and I just wanted to verify that scripts we write today in a certain version format will be able to be executed at some point down the line, regardless of how far CWL evolves.
@mr-c I remember discussing that you could have full paths in InitialWorkDir to set mount points in Docker, I thought we were going to formalize that behavior but I can't find any documentation
(this might possibly be something that was added as a conformance test but not added into the text)
@nathanielmki about mounting things in docker -- this would be a good topic for the forum https://cwl.discourse.group/
anyway relevant PR is here - not sure if my approach is the "correct approach": common-workflow-library/bio-cwl-tools#94
which is what the original code was doing I think
so I don't understand the problem that you're trying to solve
and the existing tools do not match up the secondaryFiles between the two tools - in fact the
BWA-Index tool does not produce secondaryFiles.
and yes it shoud.
should
anyway here is the new PR common-workflow-library/bio-cwl-tools#95 - and it all works in local testing (as individual tools or with a workflow) but if you flip the cwlVersion to v1.1 for the BWA-Index tool then the workflow throws a runtime error in the cwltool checker.
I guess this is a cwltool bug?
Is it possible to have 2 arrays as input and for each first element run a step and for the second element in each array run that step as well? As we have a workflow for input > quality > assembly in which quality accepts only 1 input file and the assembly accepts multiple input files. Meaning that if we have a paired set of input1 and input2 and another set of input3 and input 4 the inputs will be
forward input1, input3
reverse input2, input4
then the first group (1,2) runs through the quality and in parallel or separately (3,4) are sent through. Then the result of that are two arrays input1a,input3a and input2a,input4a which is then sent to the next application.
Thinking about this i might make things more complicated than it should be?
hmm i could generate a bash script for each input set