data2semantics/ducktape

Ducktape

ducktape's Issues

Modules with no input

If a module has no input, the yaml description should not require the "input:" key. Currently the parsing crashes.

As a workaround, you can use "input: {}".

Large datasets as intermediates

If a large dataset is loaded and passed between modules, for instance an RDF graph, the whole thing is printed to the output stream, even if the outputs have the "no print" flag. This should be unit tested and checked.

ModuleInstances should be executed as processes, not threads

Also in the LocalExecutionProfile.

This would help us to create an environment where every module (in whatever domain) can just write to the current working directory, current in/out etc. and ducktape will catch it, and put it in the right place.

With any other solution (like threads) the modules must be written with techniques that are specific to ducktape, which is what we're trying to avoid.

The only problem is that this might increase the overhead, but probably not by that much.

Missing module argument does not cause error

If a module is constructed with an integer argument, and this argument is not supplied, the workflow compiles and executed with the default value 0, instead of giving an error as it should. This may be a problem with the logic of default values.