Galaxy-Inspired Features to Consider about common-workflow-language HOT 4 OPEN

Re DOIs, since we'll likely want more metadata for the underlying app, perhaps we can use a nested DOAP object:

class: CommandLineTool
label: "samtools sort"
application:
  id: doi:10.1000/1234
  doap:name: samtools
  doap:description: "Samtools is..."
  doap:license: spdx:MIT
  doap:homepage: "http://samtools.sourceforge.net/"
  doap:repository: "https://github.com/samtools/samtools"
  doap:revision: "1.2"

Re version of the tool document, I'm not sure how to approach this. I'd prefer if the top-level identifier was a URL for the specific (immutable) revision of the document and use some other property to signify that e.g. "samtools_sort_0.1" and "samtools_sort_0.2" are different revisions of "samtools_sort". Perhaps use top-level doap:name and doap:revision for this purpose?

Re custom environment requirements, it should be done via custom value for the class property in the requirements list. For example:

class: CommandLineTool
label: wget
requirements:
  - class: galaxy:AptPackageRequirement
    galaxy:package_name: wget

For the above tool, a platform that doesn't recognize galaxy:AptPackageRequirement should refuse to run it.

If you want to leave optional execution environment "hints", use the hints property:

class: CommandLineTool
hints:
  - class: galaxy:PreferredEC2InstanceType
    value: m1.large

For the above tool, a platform that doesn't recognize galaxy:PreferredEC2InstanceType can ignore it.

There's currently no way to specify alternate sets of requirements, but it feels like it's something we can add later while keeping backward-compatibility (e.g. though a OneOfRequirement type).

Regarding conditional outputs, personally, I don't think we should use them in the manner proposed in that issue. Rather, they could simply be UI hints.

from common-workflow-language.

From this week's call I think we identified a general need to specify how to extract a tool's version; should this be split out into its own issue?

from common-workflow-language.

Yeah, we should start splitting feature requests/ideas in own issues.

from common-workflow-language.

Somehow I feel that there are some things mixed up. A CWL command line describes just that. A command line may require a particular software to be installed or that executed tool already comes with the base installation on a particular platform. For instance above referenced wget does not need to get installed on Mac OS X, if I am not erroneous. The workflow shoud just work, then, and not be ignored.

The challenge is to clarify that the wget the workflow demands is the same that a distribution's cognate package provides. This is not always the case. For excample it is sheer luck that I was once the first to provide a package called muscle, which is also a communication thing. And we had a conflict with plink which is also in the package putty. All these subtle differences across platforms shall not be expressed in the command line description itself. Instead, the command should refer to an abstract namespace/registry to identify the means to install a software that will provide the right binary.

Different platforms then make different proposals on how to install the command. And one platform could inherit such proposals from another. This will come particularly handy for cloud images that will differ in their wealth of packages that these already provide, but a particular resource may declare to be a derivative of Debian stable, such that anything not already provided would then be installed the same way that it would on any other Debian stable release.

from common-workflow-language.