ducttape
ducttape copied to clipboard
jhclark
A workflow management system for researchers who heart Unix.
Certain submitter variables may only be used in advanced special circumstances, or may have reasonable default values set by the submitter administrator. It would be nice to allow the submitter...
To allow for the use of highly experimental code such as the tape linked below, allow the following: https://github.com/jhclark/ducttape/blob/master/syntax/crazy-ideas/lane-advanced-moses-package.tape task foo :: .versioner=git .url="git://path/to/software.git" .ref=HEAD { # Do something }
The parser for the bash code blocks should detect this error at parse time: task foo < // this is a valid ducttape comment { // this is an illegal...
I just noticed a syntax highlighting issue that might be a case against /\* comments */. Consider the following bash glob: ``` tar -xvzf file.tgz dir/* ls file.tgz ``` Under...
If multiple people have written configs for a very similar .tape file, we would like to detect similarities and not do extra work where we dont have to. For example:...
If the user specifies different workflow filenames or different config names to be output into the same directory, they should be warned, in case they accidentally ran two different commands...
It would be nice to allow the following: task foo :: dir=path/to/dir > a=$dir/a.txt > b=$dir/b.txt { ... Bash code ... }
When a ducttape process exists, lock files are not always removed, despite having `finally {}` blocks in several places. Perhaps this can be fixed with an exit hook?
Consider this workflow: ``` task tokenize < corpus=@ > tok {} task learn < tok=@tokenize {} ``` A few use cases from MT pipelines: 1) Your basic workflow contains a...
For tapes where only one config block is found, the following should run, even if -c is not provided: ``` task hello :: message=@ { echo ${message} } config es...