Use the log directive from the start

[tbooth]

From @cmeesters:

the log directive is crucial. There is no rule, using it, no task implementing it. No lookup performed by the participants.

log is its own directive, not a part of the output directive. The shown solution does work, but separating logs and
outputs is a jolly good idea - mixing it up will lead to quirky workflows.

to use the log directives, you can use cmd -i {input} -o {output} &> {log} for ordinary commands.

[tbooth]

The log directive in Snakemake is a special type of output that does not get deleted if a job fails. Outside of failure conditions, both output and log are treated the same (you can s/output/log/g or vice versa and the workflow still operates). I agree that using {output.log} is a bad habit, and at a minimum I should change this to, say, {output.messages}. Later on having the console messages as an actual output makes sense in the context of running MultiQC, where the STDERR of kallisto quant provides the input needed by the multiqc program and is not just a log file.

The changes suggested in issue #59 might help resolve this, in that we could introduce a rule with multiple inputs and outputs before adding Kallisto or other applications we would want to log. Then I can introduce the {log} directive properly once multiple inputs and outputs are already covered, rather than conflating the two.