Package list ctdconverter / 01f3fa5
Fixed typos, etc., in README.md. Luis de la Garza 4 years ago
1 changed file(s) with 12 addition(s) and 9 deletion(s). Raw diff Collapse all Expand all
88 - `pyyaml`
99
1010 ### Installing Dependencies
11 The easiest way is to install [CTDopts] and all required dependencies modules via `conda`, like so:
11 The easiest way is to install all required dependencies using `conda`, like so:
1212
1313 ```sh
1414 $ conda install lxml pyyaml
2020 ### Issues with `libxml2` and Schema Validation
2121 `lxml` depends on `libxml2`. When you install `lxml` you'll get the latest version of `libxml2` (2.9.4) by default. You would usually want the latest version, but there is, however, a bug in validating XML files against a schema in this version of `libxml2`.
2222
23 If you require validation of input CTDs against a schema (which we recommend), you will need to downgrade to the latest known version of `libxml2` that works, namely, 2.9.2. You can do it by executing the following command **after** you've installed all other dependencies:
23 If you require validation of input CTDs against a schema (which we recommend), you will need to downgrade to the latest known version of `libxml2` that works, namely, 2.9.2. You can do this by executing the following command **after** you've installed all other dependencies:
2424
2525 ```sh
2626 $ conda install -y libxml2=2.9.2
2727 ```
2828
29 You will be warned that this command will downgrade some packages, which is fine, don't worry. The `-y` flag tells `conda` to perform the installation without confirmation.
29 The `-y` flag tells `conda` to perform the installation without confirmation. You will be warned that this command will downgrade some packages, which is fine, don't worry.
3030
3131 ## How to install `CTDConverter`
3232 `CTDConverter` is not a python module, rather, a series of scripts, so installing it is as easy as downloading the source code from https://github.com/genericworkflownodes/CTDConverter.
3636
3737 $ python convert.py [FORMAT] [ADDITIONAL_PARAMETERS ...]
3838
39 Here `[FORMAT]` can be any of the supported formats (i.e., `cwl`, `galaxy`). `CTDConverter` offers a series of format-specific scripts and we've designed these scripts to behave *somewhat* similarly. All converter scripts have the same core functionality, that is, read CTD files, parse them using [CTDopts], validate against a schema, etc. Of course, each converter script might add extra functionality that is not present in other engines, for instance, only the Galaxy converter script supports generation of a `tool_conf.xml` file.
39 Here `[FORMAT]` can be any of the supported formats (i.e., `cwl`, `galaxy`). `CTDConverter` offers a series of format-specific scripts and we've designed these scripts to behave *somewhat* similarly. All converter scripts have the same core functionality, that is, read CTD files, parse them using [CTDopts], validate against a schema, etc. Of course, each converter script might add extra functionality that is not present in other engines. Only the Galaxy converter script supports generation of a `tool_conf.xml` file, for instance.
4040
4141 The following sections in this file describe the parameters that all converter scripts share.
4242
7171 * Required: yes.
7272 * Taken values: a list of input CTD files.
7373
74 Example:
74 Examples:
7575
7676 Any of the following invocations will convert `/data/input_one.ctd` and `/data/input_two.ctd`:
7777
9393 * Purpose: Provide output destination for the converted wrapper files.
9494 * Short/long version: `-o` / `--output-destination`
9595 * Required: yes.
96 * Taken values: if a single input file is given, then a single output file is expected. If multiple input files are given, then an existent folder, in which all converted CTDs will be written, is expected.
96 * Taken values: if a single input file is given, then a single output file is expected. If multiple input files are given, then an existent folder in which all converted CTDs will be written is expected.
9797
9898 Examples:
9999
104104 Several inputs are given. The output is the already existent folder, `/data/wrappers`, and at the end of the operation, the files `/data/wrappers/input_one.[EXT]` and `/data/wrappers/input_two.[EXT]` will be generated:
105105
106106 $ python convert.py [FORMAT] -i /data/ctds/input_one.ctd /data/ctds/input_two.ctd -o /data/stubs
107
108 Please note that the output file name is **not** taken from the name of the input file, rather from the name of the tool, that is, from the `name` attribute in the `<tool>` element in its corresponding CTD. By convention, the name of the CTD file and the name of the tool match.
107109
108110 ### Blacklisting Parameters
109111 * Purpose: Some parameters present in the CTD are not to be exposed on the output files. Think of parameters such as `--help`, `--debug` that might won't make much sense to be exposed to final users in a workflow management system.
123125 * Required: no.
124126 * Taken values: location of the schema file (e.g., CTD.xsd).
125127
126 CTDs can be validated against a schema. The master version of the schema can be found under [CTDSchema].
128 CTDs can be validated against a schema. The master version of the schema can be found on [CTDSchema].
127129
128130 If a schema is provided, all input CTDs will be validated against it.
129131
135137 * Required: no.
136138 * Taken values: The path of a file containing the mapping between parameter names and hardcoded values to use.
137139
138 It is sometimes required that parameters are hidden from the end user in workflow systems and that they take a predetermined, fixed value. Allowing end users to control parameters similar to `--verbosity`, `--threads`, etc., might create more problems than solving them. For this purpose, the parameter `p`/`--hardcoded-parameters` takes the path of a file that contains up to three columns separated by whitespace that map parameter names to the hardcoded value. The first column contains the name of the parameter and the second one the hardcoded value. The first two columns are mandatory.
140 It is sometimes required that parameters are hidden from the end user in workflow systems and that they take a predetermined, fixed value. Allowing end users to control parameters similar to `--verbosity`, `--threads`, etc., might create more problems than solving them. For this purpose, the parameter `-p`/`--hardcoded-parameters` takes the path of a file that contains up to three columns separated by whitespace that map parameter names to the hardcoded value. The first column contains the name of the parameter and the second one the hardcoded value. Only the first two columns are mandatory.
139141
140142 If the parameter is to be hardcoded only for certain tools, a third column containing a comma separated list of tool names for which the hardcoding will apply can be added.
141143
142144 Lines starting with `#` will be ignored. The following is an example of a valid file:
143145
144 # Parameter name # Value # Tool(s)
146 # Parameter name # Value # Tool(s)
145147 threads 8
146148 mode quiet
147149 xtandem_executable xtandem XTandemAdapter
163165
164166
165167 [CTDopts]: https://github.com/genericworkflownodes/CTDopts
168 [CTDSchema]: https://github.com/WorkflowConversion/CTDSchema