Work in progress: CWL tool descriptions

[mr-c]

Please don't merge yet, thanks!

• add default values to match the Galaxy tool descriptions

http://www.commonwl.org/user_guide/rec-practices/

• No type: string parameters for names of input or reference files/directories; use type: File or type: Directory as appropriate.
• Include a license that allows for re-use by anyone, e.g. Apache 2.0. Example of license inclusion.
• Include attribution information for the author(s) of the CWL tool or workflow description. Use unambiguous identifiers like ORCID.
• In tool descriptions, list dependencies using short name(s) under SoftwareRequirement.
• Include SciCrunch identifiers for dependencies in https://identifiers.org/rrid/RRID:SCR_NNNNNN format.
• All input and output identifiers should reflect their conceptual identity. Use informative names like unaligned_sequences, reference_genome, phylogeny, or aligned_sequences instead of foo_input, foo_file, result, input, output, and so forth.
• In tool descriptions, include a list of version(s) of the tool that are known to work with this description under SoftwareRequirement.
• format should be specified for all input and output Files. Bioinformatics tools should use format identifiers from EDAM. See also iana:text/plain, iana:text/tab-separated-values with $namespaces: { iana: "https://www.iana.org/assignments/media-types/" }. Full IANA media type list(also known as MIME types). For non-bioinformatics tools use or build an appropriate ontology/controlled vocabulary in the same way.
• Mark all input and output Files that are read from or written to in a streaming compatible way (only once, no random-access), as streamable: true.
• Each CommandLineTool description should focus on a single operation only, even if the (sub)command is capable of more. Don’t overcomplicate your tool descriptions with options that you don’t need/use.
• Custom types should be defined with one external YAML per type definition for re-use.
• Include a top level short label summarising the tool/workflow.
• If useful, include a top level doc as well. This should provide a longer, more detailed description than was provided in the top level label (see above).
• Use type: enum instead of type: string for elements with a fixed list of valid values.
• Evaluate all use of JavaScript for possible elimination or replacement. One common example: manipulating File names and paths? Consider whether one of the built-in in File properties like basename, nameroot, nameext, etc, could be used instead.
• Give the tool description to a colleague (preferably at a different institution) to test and provide feedback.

[pcm32]

Hi Michael! Nice to see you around. When you have time, could you give us a bit of background of what you're after with the PR? Thanks!

[mr-c]

Hey @pcm32

Several people (@proccaserra @RJMW @rsalek @djcomlab @agbeltran) are in Hong Kong for http://cuddel.net/ 2017

For the next Phenomenal release I am contributing a CWL version of some of the Galaxy tools and a new workflow we are putting together as a group.

[pcm32]

Thanks @mr-c, sounds great. So I wonder, is galaxy able to read the cwl specification now and use it for tools? or how are these tools triggered to execute?

[mr-c]

@pcm32 Based upon https://github.com/common-workflow-language/galaxy/issues I don't think Galaxy is ready to read the CWL versions yet. Pinging @jmchilton to correct the record.

Once the team has gotten the Galaxy workflow more developed I'll synchronize with them to update the CWL version.

[sneumann]

Hi @mr-c , our next release is coming up and we'll have code freeze in July.
That release will be based on Galaxy 18.01.
Any idea about the progress here ? Yours, Steffen

[mr-c]

Hello @sneumann While there is an additional engineer helping out, Galaxy 18.01 does not support reading CWL yet.