Liu 253 - Issue with appended reprodata

[pritchardn]

PR #133 added a signature mechanism, which passes additional information alongside a graph from translation to execution.

The default value of this 'reprodata' in the PGT object is an empty dictionary but will non-empty if prior layers called their respective init_lgt/lg_reprodata functions.
Since EAGLE is not yet configured to pass a reproducibility mode flag to the translator (yet), these functions are never called, leaving the PGT with the default value of an empty dictionary.

There is logic in the composite_manager when loading a graph to remove the appended reprodata, avoiding loading this information as a drop by checking if the last item in the dropspec (which is expected to be the reprodata) contains an rmode flag. This failed if the final drop in the list is an empty dictionary, the default value in the case of no rmode being specified in prior layers.

This PR changes that logic to additionally check for an empty dictionary at the end of the PGT and provides specific tests for this case in test_dim.py

[coveralls]

Coverage increased (+0.008%) to 81.046% when pulling bee8b98 on LIU-253 into 52c3dce on master.

[awicenec]

This seems fine, I just have a question about the difference between submitting a graph through the dlg CLI and through the web interface. The bug only appeared on the web interface, not the CLI, is that the expected behavior?

[pritchardn]

Somewhat intended; I had recently made a change to what the default (rmode.NOTHING) practically meant which I think caused this issue.
Instead of appending empty reprodata values everywhere containing only the flag and nothing else, this flag now actually appends nothing - to provide some way to maintain the old pre-merge behaviour (at least for now).

The CLI functions are wrapped at a different level, and do the final 'resource map' step slightly differently - the web interface calls pgt.to_pg_spec, the CLI calls pg_generator.resource_map - I've added the required init_pg_reprodata method so they should at least be in parity with each other now

[pritchardn]

There's actually an even simpler cause - when merging the latest changes from master -> 919 before merging 919 -> master - I mistakenly erased a prepare_lgt step from gen_pgt (POST) which added the reprodata to submitted graphs.

The changes made to the composite-manager are still useful and my confusion around this is now satisfied - I had been submitting graphs through the web with all the reprodata attached without issue before merging, so this one surprised me.