通用工作流语言参考实现
项目描述
PyPI: 
Conda: 
Debian: 
Quay.io (Docker):
这是 Common Workflow Language 开放标准 的参考实现。它旨在功能完整，并提供对 CWL 文件的综合验证，同时提供其他与 CWL 相关的工具。
cwltool 是为 Python 3.x {x = 6, 8, 9, 10, 11} 编写和测试的
参考实现由两个包组成。 cwltool 包是主要 Python 模块，包含 cwltool 模块和同名的控制台可执行文件。
cwlref-runner 包是可选的，并在别名 cwl-runner 下提供额外的入口点，这是主机上默认安装的 CWL 解释器的实现无关名称。
cwltool 由 CWL 项目提供，该项目是 软件自由保护协会的成员项目，以及我们的 众多贡献者。
安装
cwltool 包
您的操作系统可能直接提供 cwltool。对于 Debian，Ubuntu 和类似的 Linux 发行版，请尝试
sudo apt-get install cwltool如果您遇到错误，首先尝试使用
sudo apt-get update如果您正在运行macOS X或其他UNIX系统，并且希望使用conda-forge项目准备的软件包，请按照conda-forge的安装说明进行操作（如果您尚未这样做），然后
conda install -c conda-forge cwltool上述所有安装cwltool的方法都使用可能包含已在新版本中修复的错误或缺少所需功能的软件包。如果您可用的cwltool软件包版本太旧，我们建议使用pip和venv进行安装
python3 -m venv env # Create a virtual environment named 'env' in the current directory
source env/bin/activate # Activate environment before installing `cwltool`然后从PyPi安装最新的cwlref-runner软件包（这将安装最新的cwltool软件包）
pip install cwlref-runner如果与另一个CWL实现（如toil-cwl-runner或arvados-cwl-runner）一起安装，则请运行以下命令
pip install cwltoolMS Windows 用户
将Debian设置为默认的WSL 2发行版：wsl --set-default debian。
返回Docker Desktop，选择设置 → 资源 → WSL集成，然后在“启用与附加发行版的集成”下选择“Debian”，
如果您尚未重启，请重启
启动Debian并遵循上面的Linux指令（使用apt-get install cwltool或使用venv方法）
WSL2内部存在网络问题？请尝试这些说明，然后执行wsl --shutdown。
cwltool 开发版本
或者，您可以跳过上面的直接pip命令，并安装最新的cwltool开发版本
git clone https://github.com/common-workflow-language/cwltool.git # clone (copy) the cwltool git repository
cd cwltool # Change to source directory that git clone just downloaded
pip install .[deps] # Installs ``cwltool`` from source
cwltool --version # Check if the installation works correctly记住，如果同时安装多个CWL实现，则需要通过符号文件系统链接或其他设施维护指向cwl-runner的实现
推荐软件
我们强烈建议安装以下软件
以下软件容器引擎之一
Singularity/Apptainer：请参阅使用Singularity
udocker：请参阅使用uDocker
node.js，用于快速评估CWL表达式（对于udocker用户是必需的，对于其他容器引擎是可选的但推荐使用）
如果没有这些软件，http://www.commonwl.org/user_guide/上的某些CWL教程示例可能无法正常工作。
在命令行上运行
简单命令
cwl-runner my_workflow.cwl my_inputs.yaml
或者，如果您已安装多个CWL实现，并希望覆盖默认的cwl-runner，请使用
cwltool my_workflow.cwl my_inputs.yml
您可以使用CWLTOOL_OPTIONS在环境中设置cwltool选项，这些选项将被插入到命令行开头
export CWLTOOL_OPTIONS="--debug"
与 macOS 上的 boot2docker 一起使用
boot2docker在虚拟机内部运行Docker，并且它只挂载Users。CWL的默认行为是在例如/Var下创建临时目录，这些目录对Docker容器不可访问。
要使用boot2docker成功运行CWL，您需要将--tmpdir-prefix和--tmp-outdir-prefix设置在/Users下的某个位置
$ cwl-runner --tmp-outdir-prefix=/Users/username/project --tmpdir-prefix=/Users/username/project wc-tool.cwl wc-job.json
使用 uDocker
某些共享计算环境由于技术或政策原因不支持Docker软件容器。作为替代方案，CWL参考运行器支持在Linux上使用--udocker通过udocker程序。
udocker 安装：请参阅https://indigo-dc.github.io/udocker/installation_manual.html
像平常一样运行 cwltool，但在工作流程路径之前加上 --udocker
cwltool --udocker https://github.com/common-workflow-language/common-workflow-language/raw/main/v1.0/v1.0/test-cwl-out2.cwl https://github.com/common-workflow-language/common-workflow-language/raw/main/v1.0/v1.0/empty.json正如在推荐软件部分所提到的，
使用 Singularity
cwltool 也可以使用 Singularity 版本 2.6.1 或更高版本作为 Docker 容器运行时。使用 Singularity 的 cwltool 将会运行在 DockerRequirement 中指定的软件容器，因此它只与 Docker 镜像一起工作，不支持原生 Singularity 镜像。要使用 Singularity 作为 Docker 容器运行时，向 cwltool 提供命令行选项 --singularity。使用 Singularity，cwltool 可以通过所有 CWL v1.0 合规性测试，除了涉及 Docker 容器 ENTRYPOINTs 的测试。
示例
cwltool --singularity https://github.com/common-workflow-language/common-workflow-language/raw/main/v1.0/v1.0/cat3-tool-mediumcut.cwl https://github.com/common-workflow-language/common-workflow-language/raw/main/v1.0/v1.0/cat-job.json从远程或本地位置运行工具或工作流程
cwltool 可以通过其对 HTTP[S] URL 的支持在本地和远程系统上运行工具和工作流程描述。
输入作业文件和工作流程步骤（通过 run 指令）可以使用绝对或相对本地文件系统路径引用 CWL 文档。如果引用了相对路径并且该文档未在当前目录中找到，则将在以下位置搜索：http://www.commonwl.org/v1.0/CommandLineTool.html#Discovering_CWL_documents_on_a_local_filesystem
您还可以使用 cwldep 来管理外部工具和工作流程的依赖关系。
在加载时覆盖工作流程要求
有时工作流程需要额外的需求才能在特定环境中或与特定数据集一起运行。为了避免修改底层工作流程，cwltool 支持需求“覆盖”。
“覆盖”对象的格式是将项目标识符（工作流程、工作流程步骤或命令行工具）映射到应应用的过程需求。
cwltool:overrides:
echo.cwl:
requirements:
EnvVarRequirement:
envDef:
MESSAGE: override_value覆盖可以在命令行上指定，也可以作为作业输入文档的一部分。使用工作流程文件名称后跟步骤名称作为文档片段标识符“#id”来标识工作流程步骤。覆盖标识符相对于顶层工作流程文档。
cwltool --overrides overrides.yml my-tool.cwl my-job.ymlinput_parameter1: value1
input_parameter2: value2
cwltool:overrides:
workflow.cwl#step1:
requirements:
EnvVarRequirement:
envDef:
MESSAGE: override_valuecwltool my-tool.cwl my-job-with-overrides.yml将工作流程的各个部分组合成一个文档
使用 --pack 将由多个文件组成的工作流程组合成一个单一复合文档。此操作获取工作流程引用的所有 CWL 文件，并构建一个新的 CWL 文档，其中所有 Process 对象（CommandLineTool 和 Workflow）都在 $graph 字段中的列表中。交叉引用（如 run: 和 source: 字段）已更新为新的打包文档内部引用。顶层工作流程命名为 #main。
cwltool --pack my-wf.cwl > my-packed-wf.cwl仅运行工作流程的一部分
您可以使用 --target (-t) 选项运行部分工作流程。这需要顶层工作流程中输出参数、工作流程步骤或输入参数的名称。您可以提供多个目标。
cwltool --target step3 my-wf.cwl如果目标是输出参数，它将只运行贡献该输出的步骤。如果目标是工作流程步骤，它将从该步骤开始运行工作流程。如果目标是输入参数，它将只运行与该输入相关的步骤。
使用 --print-targets 获取工作流程目标列表。要查看哪些步骤将运行，请使用 --print-subgraph 与 --target 结合，以获取所选目标的打印工作流程子图。
cwltool --print-targets my-wf.cwl
cwltool --target step3 --print-subgraph my-wf.cwl > my-wf-starting-from-step3.cwl可视化 CWL 文档
使用 --print-dot 选项将打印适合 Graphviz dot 程序的文件。以下是一个用于生成可伸缩矢量图形（SVG）文件的 bash 命令行示例
cwltool --print-dot my-wf.cwl | dot -Tsvg > my-wf.svg将 CWL 文档建模为 RDF
CWL 文档可以表示为 RDF 三元图。
cwltool --print-rdf --rdf-serializer=turtle mywf.cwlcwltool 中的环境变量
此参考实现支持设置环境变量的方法，除了标准的 EnvVarRequirement 以外。创建环境的步骤顺序是
如果存在 --preserve-entire-environment 标志，则从当前环境开始，否则从空环境开始。
添加由 --preserve-environment 选项指定的任何变量。
按照 CWL v1.0+ CommandLineTool 规范 设置 TMPDIR 和 HOME。
应用 CommandLineTool 描述中的任何 EnvVarRequirement。
应用任何由 cwltool:MPIRequirement 扩展要求的操作。
替换 Secrets 扩展所需的任何密钥。
根据 SoftwareRequirement（见下文）修改环境。
利用 SoftwareRequirements（Beta）
CWL 工具可以带有 SoftwareRequirement 提示，cwltool 可以使用这些提示将包解析为各种包管理器或依赖关系管理系统中的包，例如 Environment Modules。
使用 cwltool 的 SoftwareRequirement 提示需要可选依赖，因此请确保在安装 cwltool 时指定 deps 修饰符。例如
$ pip install 'cwltool[deps]'
以这种方式安装 cwltool 可以启用几个新的命令行选项。其中最通用的是 --beta-dependency-resolvers-configuration 选项。此选项允许指定依赖解析器的配置文件。此文件可以是 XML 或 YAML 格式，非常简单，描述了各种插件以启用“解析” SoftwareRequirement 依赖关系。
使用这些提示将允许 cwltool 修改工具运行时的环境，例如通过加载一个或多个环境模块。环境按上述方式构建，然后环境可能被选定的工具解析器修改。这意味着您不能覆盖由选定的工具解析器设置的任何环境变量。请注意，配置的依赖解析器给出的环境变量 _CWLTOOL 设置为 1 以允许内省。
为了讨论一些这些插件及其配置方法，首先考虑以下示例 CWL 工具的 hint 定义。
SoftwareRequirement:
packages:
- package: seqtk
version:
- r93现在想象在一个已安装软件模块的集群上部署 cwltool，并且有一个 seqtk 模块可供使用，版本为 r93。这意味着集群用户默认情况下不会在他们的 PATH 上有 seqtk 二进制文件，但通过使用 modulecmd sh load seqtk/r93 命令来源此模块后，seqtk 就会出现在 PATH 上。一个简单的依赖解析器配置文件，例如名为 dependency-resolvers-conf.yml 的文件，将允许 cwltool 在执行上述工具之前源正确的模块环境，内容如下
- type: modules外部列表表示正在启用一个插件，该插件参数定义为该列表项的一个字典。上述插件只有一个必需的参数，这是 type，它定义了插件类型。所有插件都需要此参数。有关可用插件以及每个插件可用的参数的文档（不完整）请参见此处。遗憾的是，该文档是在 Galaxy 工具 requirement 的上下文中编写的，而不是 CWL SoftwareRequirement，但概念映射相当直接。
cwltool 伴随着一个这样的 seqtk 工具示例和相应的作业样本。它可以通过使用类似上述依赖解析器配置文件从 cwltool 根目录执行。
cwltool --beta-dependency-resolvers-configuration /path/to/dependency-resolvers-conf.yml \
tests/seqtk_seq.cwl \
tests/seqtk_seq_job.json
此示例演示了 cwltool 可以利用现有的软件安装，并且也可以处理依赖于相同软件和库的不同版本的流程。然而，上述示例确实需要现有的模块设置，因此不可能用 cwltool 直接测试此示例。为了进行更独立的测试，以演示所有相同的概念 - 可以使用解析器插件类型 galaxy_packages。
“Galaxy packages” 是 Environment Modules 的轻量级替代品，它实际上只是通过一种方式来布局目录和版本，以找到用于修改环境的源脚本。这些脚本已经在 Galaxy 社区中使用多年，以将 Galaxy 工具适应集群环境，但不需要了解 Galaxy 或任何特殊工具来设置。它们应该适用于 CWL 工具。
cwltool 源代码仓库的测试目录设置了一个非常简单的目录，该目录定义了一组“Galaxy packages”（但实际上只定义了一个名为 random-lines 的包）。目录布局非常简单：
tests/test_deps_env/
random-lines/
1.0/
env.sh
如果启用了 galaxy_packages 插件，并将其指向 cwltool 根目录中的 tests/test_deps_env 目录，并且遇到了以下 SoftwareRequirement：
hints:
SoftwareRequirement:
packages:
- package: 'random-lines'
version:
- '1.0'那么 cwltool 将简单地找到那个 env.sh 文件，并在执行相应的工具之前源它。那个 env.sh 脚本只负责修改作业的 PATH 以添加所需的二进制文件。
这是一个完整的示例，因为它解决“Galaxy packages”没有外部要求。尝试从 cwltool 的根目录执行以下命令进行测试：
cwltool --beta-dependency-resolvers-configuration tests/test_deps_env_resolvers_conf.yml \
tests/random_lines.cwl \
tests/random_lines_job.json
上述示例中的解析器配置文件很简单：
- type: galaxy_packages
base_path: ./tests/test_deps_env可能给定的 CWL 工具中的 SoftwareRequirement 不会与特定集群的模块名称匹配。可以使用解析器插件参数 mapping_files 指定另一个文件来重新映射到特定的已部署包或版本。我们将使用 galaxy_packages 来演示这一点，但同样适用于 Environment Modules 或 Conda packages（下面描述），例如。
因此请考虑解析器配置文件。（tests/test_deps_env_resolvers_conf_rewrite.yml）
- type: galaxy_packages
base_path: ./tests/test_deps_env
mapping_files: ./tests/test_deps_mapping.yml以及相应的映射配置文件（tests/test_deps_mapping.yml）
- from:
name: randomLines
version: 1.0.0-rc1
to:
name: random-lines
version: '1.0'这是说，如果cwltool在工具中遇到版本1.0.0-rc1中randomLines的要求，则将其重写为我们特定的插件版本1.0中的random-lines。cwltool有一个名为random_lines_mapping.cwl的测试工具，其中包含这样的SoftwareRequirement源代码。要尝试使用以下命令从cwltool根目录执行此示例中的映射
cwltool --beta-dependency-resolvers-configuration tests/test_deps_env_resolvers_conf_rewrite.yml \
tests/random_lines_mapping.cwl \
tests/random_lines_job.json
前面的示例演示了利用现有基础设施为CWL工具提供要求。如果使用实际的包管理器，cwltool有机会根据需要安装要求。虽然已经提供了对Homebrew/Linuxbrew插件的初始支持，但最发达的此类插件是针对Conda包管理器的。Conda具有允许同时安装多个版本的包、无需评估权限即可安装Conda自身或使用Conda的包、并且跨平台等良好特性。因此，cwltool可以作为普通用户运行，安装其自己的Conda环境，并在Linux和Mac OS X上管理多个版本的Conda包。
Conda插件可以进行无限配置，但通过简单地传递--beta-conda-dependencies标志给cwltool，就可以启用一组合理的默认设置，这已被证明是Galaxy工具开发生态系统内部依赖关系管理的一个强大堆栈。
有了这个，我们可以使用上面提到的seqtk示例，而无需Docker或任何外部管理服务 - cwltool应安装所需的所有内容并为工具创建一个环境。尝试使用以下命令进行测试
cwltool --beta-conda-dependencies tests/seqtk_seq.cwl tests/seqtk_seq_job.json
CWL规范允许将URI附加到SoftwareRequirement，以允许消除包名称的歧义。如果上述映射文件允许部署者将工具适配到他们的基础设施，则此机制允许工具将他们的要求适配到多个包管理器。为了在seqtk的上下文中演示这一点，我们可以简单地分解我们使用的包名称，然后按照以下方式指定一个特定的Conda包
hints:
SoftwareRequirement:
packages:
- package: seqtk_seq
version:
- '1.2'
specs:
- https://anaconda.org/bioconda/seqtk
- https://packages.debian.org/sid/seqtk可以使用以下命令执行此示例
cwltool --beta-conda-dependencies tests/seqtk_seq_wrong_name.cwl tests/seqtk_seq_job.json
用于管理这些软件要求解析的插件框架作为galaxy-tool-util（Galaxy项目的一个小型、可移植的子集）的一部分维护。有关配置和实现的更多信息，请参阅以下链接
与 GA4GH 工具注册 API 一起使用
cwltool可以从GA4GH工具注册API端点直接启动工具。
默认情况下，cwltool搜索https://dockstore.org/。使用--add-tool-registry将其他注册表添加到搜索路径。
例如
cwltool quay.io/collaboratory/dockstore-tool-bamstats:develop test.json
（未指定版本时默认为最新版本）
cwltool quay.io/collaboratory/dockstore-tool-bamstats test.json
对于这个示例，从https://github.com/CancerCollaboratory/dockstore-tool-bamstats获取test.json（和输入文件）
wget https://dockstore.org/api/api/ga4gh/v2/tools/quay.io%2Fbriandoconnor%2Fdockstore-tool-bamstats/versions/develop/PLAIN-CWL/descriptor/test.json wget https://github.com/CancerCollaboratory/dockstore-tool-bamstats/raw/develop/rna.SRR948778.bam
运行需要启动的基于 MPI 的工具
Cwltool支持对CWL规范的扩展http://commonwl.org/cwltool#MPIRequirement。当工具定义在它的requirements/hints部分包含此内容，并且cwltool已使用--enable-ext运行时，工具的命令行将扩展为启动mpirun或类似命令所需的命令。您可以将启动进程的数量指定为文字整数或表达式（结果为整数）。例如
#!/usr/bin/env cwl-runner
cwlVersion: v1.1
class: CommandLineTool
$namespaces:
cwltool: "http://commonwl.org/cwltool#"
requirements:
cwltool:MPIRequirement:
processes: $(inputs.nproc)
inputs:
nproc:
type: int
与容器的交互：目前MPIRequirement将命令添加到构建的命令行前面。如果您希望在并行运行容器化应用程序，对于简单的用例，这在使用Singularity的情况下可以工作，取决于平台设置。然而，这种组合应被视为“alpha”版本——请务必报告您遇到的所有问题！目前它不与Docker兼容。（更确切地说，您将得到n个相同的单个进程映像副本同时运行，它们无法相互通信。）
特定于主机的参数配置在一个简单的YAML文件中（使用--mpi-config-file标志指定）。允许的键在以下表中给出；所有都是可选的。
键 |
类型 |
默认值 |
描述 |
|---|---|---|---|
runner |
str |
“mpirun” |
要使用的主要命令。 |
nproc_flag |
str |
“-n” |
设置启动进程数的标志。 |
default_nproc |
int |
1 |
默认进程数。 |
extra_flags |
List[str] |
[] |
要添加到runner命令行中的其他任何标志的列表。 |
env_pass |
List[str] |
[] |
A list of environment variables that should be passed from the host environment through to the tool (e.g., giving the node list as set by your scheduler). |
env_pass_regex |
List[str] |
[] |
A list of python regular expressions that will be matched against the host’s environment. Those that match will be passed through. |
env_set |
Mapping[str,str] |
{} |
A dictionary whose keys are the environment variables set and the values being the values. |
启用快速解析器（实验性）
对于非常大的工作流，cwltool可以在第一个步骤运行之前花费大量时间在初始化中。有一个实验性标志--fast-parser可以显著减少初始化开销，然而，截至本文写作，它有几个限制
一般错误报告比标准解析器差，您希望与已知正确的工作流一起使用它。
它不会检查悬空链接（这些将变成运行时错误而不是加载错误）
其他几个情况失败，如https://github.com/common-workflow-language/cwltool/pull/1720中所述
开发
在本地运行测试
运行基本测试 (/tests)
安装cwltool后，要运行基本测试，请执行以下操作
pip install -rtest-requirements.txt
pytest ## N.B. This requires node.js or docker to be available要运行所有支持Python环境的各种测试，我们使用tox。要在所有支持的Python环境中运行测试套件，首先克隆完整的代码仓库（参见上面的git clone指令），然后在终端中运行以下命令：pip install "tox<4"; tox -p
可以使用以下方式查看所有环境列表：tox --listenvs，使用以下方式运行特定的测试环境：tox -e <env name>，并且可以使用以下格式运行特定的测试：tox -e py310-unit -- -v tests/test_examples.py::test_scandeps
运行整个CWL符合性测试套件
CWL规范GitHub仓库中包含一个脚本，使用cwltest程序测试CWL实现与大量有效的CWL文件
运行这些测试的说明可以在Common Workflow Language规范仓库中找到，地址为https://github.com/common-workflow-language/common-workflow-language/blob/main/CONFORMANCE_TESTS.md。
作为模块导入
添加
import cwltool到您的脚本中。
使用cwltool在Python中运行工具或工作流程的最简单方法是使用工厂
import cwltool.factory
fac = cwltool.factory.Factory()
echo = fac.make("echo.cwl")
result = echo(inp="foo")
# result["out"] == "foo"CWL 工具控制流
关于cwltool内部工作技术概述，供维护人员参考。
使用CWL load_tool()加载文档。
从文件或URL获取文档
应用预处理（语法/标识符扩展和归一化）
根据cwlVersion验证文档
如有必要，更新文档到最新规范
使用make_tool()回调函数构造Process对象。这会产生一个CommandLineTool、Workflow或ExpressionTool。对于工作流程，这会递归地构造每个工作流程步骤。
要构造CommandLineTool、Workflow或ExpressionTool的自定义类型，提供自定义的make_tool()
在Process对象的job()方法上迭代以获取可运行的作业。
job()是一个生成器方法（使用Python迭代器协议）
每次在迭代中调用job()方法时，它返回以下之一：可运行项（具有run()方法的对象）、None（表示当前没有可运行的工作）或迭代结束（表示过程已完成）
通过调用run()来调用可运行项。这运行工具并获取输出。
输出回调报告过程的输出。
job()可以多次迭代。它将产生所有当前可运行的工作，然后产生None。
Workflow对象创建相应的WorkflowJob和WorkflowJobStep对象，以在作业调用期间保持工作流程状态。
WorkflowJob遍历每个WorkflowJobStep，并确定步骤的输入是否就绪。
当步骤就绪时，它会为该步骤构造一个输入对象，并迭代工作流程作业步骤的job()方法。
每个可运行项都返回到顶层运行循环
当步骤作业完成并收到输出回调时，将作业输出分配给工作流程步骤的输出。
当所有步骤都完成时，将中间文件移动到最终工作流程输出，删除中间目录，并调用工作流程的输出回调。
CommandLineTool作业对象产生单个可运行对象。
CommandLineTool job()方法调用make_job_runner()创建一个CommandLineJob对象
作业方法通过设置公共属性来配置CommandLineJob对象
作业方法遍历CommandLineTool的文件和目录输入，并创建一个“路径映射”。
文件从其“解析”位置映射到工具调用时将出现的“目标”路径（例如，Docker容器内的位置）。目标路径用于命令行。
使用Docker卷绑定（使用容器时）或符号链接（如果不）将文件存档到目标路径。此存档步骤使文件能够独立于其源布局进行逻辑重新排列或重命名。
CommandLineJob 的 run() 方法执行命令行工具或 Docker 容器，等待其完成，收集输出，并执行输出回调。
扩展点
以下函数可以传递给 main() 来覆盖或增强列出的行为。
- executor
executor(tool, job_order_object, runtimeContext, logger) (Process, Dict[Text, Any], RuntimeContext) -> Tuple[Dict[Text, Any], Text]
顶层工作流程执行循环的实现应该同步运行进程对象直到完成并返回输出对象。
- versionfunc
() () -> Text
返回版本字符串。
- logger_handler
logger_handler logging.Handler
日志处理器对象。
以下函数可以在 LoadingContext 中设置以覆盖或增强列出的行为。
- fetcher_constructor
fetcher_constructor(cache, session) (Dict[unicode, unicode], requests.sessions.Session) -> Fetcher
使用提供的缓存和 HTTP 会话构建 Fetcher 对象。
- resolver
resolver(document_loader, document) (Loader, Union[Text, dict[Text, Any]]) -> Text
将相对文档标识符解析为可获取的绝对标识符。
以下函数可以在 RuntimeContext 中设置以覆盖或增强列出的行为。
- construct_tool_object
construct_tool_object(toolpath_object, loadingContext) (MutableMapping[Text, Any], LoadingContext) -> Process
从文档中构造 Process 对象（例如 CommandLineTool）的钩子。
- select_resources
selectResources(request) (Dict[str, int], RuntimeContext) -> Dict[Text, int]
接收资源请求并将其转换为具体的资源分配。
- make_fs_access
make_fs_access(basedir) (Text) -> StdFsAccess
返回文件系统访问对象。
此外，当提供 Process 对象的自定义子类时，可以覆盖以下方法
- CommandLineTool.make_job_runner
make_job_runner(RuntimeContext) (RuntimeContext) -> Type[JobBase]
创建并返回一个作业运行器对象（这实现了命令行工具的具体执行）。
- Workflow.make_workflow_step
make_workflow_step(toolpath_object, pos, loadingContext, parentworkflowProv) (Dict[Text, Any], int, LoadingContext, Optional[ProvenanceProfile]) -> WorkflowStep
创建并返回一个工作流程步骤对象。
下载文件
下载适合您平台的应用程序。如果您不确定选择哪个，请了解有关安装包的更多信息。
源分发
构建分发
cwltool-3.1.20240909164951.tar.gz的哈希值
| 算法 | 哈希摘要 | |
|---|---|---|
| SHA256 | 4222c0bc21ac0be43da011fdf53bd6354f6203695f71a7e0fa46d8c3662db9ec |
|
| MD5 | 4bae2d5d5ddb743c9d55e7d8a78023c8 |
|
| BLAKE2b-256 | 0d496931c8dc4ded058eb449a5e31c4024df60e3a983f40c3a0762fec12232ea |
cwltool-3.1.20240909164951-py3-none-any.whl的哈希值
| 算法 | 哈希摘要 | |
|---|---|---|
| SHA256 | 6cee062a7d98779300db428e6f783d8c48d9940f662c5108cac49abb59abe33f |
|
| MD5 | c9490dcc8437274448863228aa2695c6 |
|
| BLAKE2b-256 | b6146fb3ec8d1e6c6b5d724e96909d12141f8216525904b8e4564f2a284eced2 |
