implement dry run

[plastikfan]

ImageMagick does not have a dry-run feature, although other external programs may have, so we need to be careful about how this is implemented. Initialy, I thought we could simlly implement --dry-run as native flag on pixa. But what happens if the users want to run a program that does have dry run feature. Does that mean we dry-run inside pixa and dry-run in the third party application (3PA)? Yes it does, we can't have a situation where there are 2 different dry run flags, one for pixa and the other for the third party application.

This can be implemented as a decorator over the path finder. When we do this, the dry run decorator can invoke the path finder, then modify the paths to suit the dry run feature.

Current methods to consider:

• Transfer(info *common.PathInfo) (folder, file string)
• Result(info *common.PathInfo) (folder, file string)

The problem with dry run comes where the input file has to be moved out of the way, for transparency purposes, ie in a real run, the original file is moved to an alterntive location (either trash or output, which ever is specified) and the result takes the place of the original file, leaving the file system in a transparent state. In these case, the 3PA is directed to look at the modified target location for its input so that it can generate the output. But if the 3PA is looking for the modified target path, it won't find it, because it will not have been created. This is what the dry run decorator takes care of. It will revert the modified back to its original and direct the 3PA to use a different output name as the original file will still be in its original location.

So in summary, --dry-run will be defined as a native flag (actually it already is, just not currenly used). This flag will be delegated to the 3PA via the executor, which in turns forwards to the agent. The agent can act appropriately and set this in the command line args if appropriate. For testing purposes, we'll have to introduce an new fake executor, which will simply create a dummy output file, mimicking the 3PA. This is good beacuse now we can adjust the tests to check for the existence of the output file.

Another point worthy of note. The configuration is validated inside the reader objects. This is a problem because, the unit tests use mocks, and thus most of the test do not excercise the validation logic. The validation should be applied to the result reading the config, rather than combining it with the read operation itself. This way, we can validate the result of the config mocks (this is a separate issue: #147).