Reorganization of evaluator code and renaming of modules

[quaquel]

In preparation for future updates to the mpi code, all evaluator code has been reorganized. All evaluators go into their respective modules, and code shared among 2 or more goes into a new util package.

tests and docs have been updated as well to reflect these changes.

[coveralls]

coverage: 80.332% (+0.08%) from 80.251%
when pulling c59ce16 on reorganization
into 2ae0278 on master.

[EwoutH]

I will try to give it a look monday!

[EwoutH]

I have a few questions:

• What was the initial motivation behind this?
• What's the idea of moving everything to files with a futures_ prefix?
• Why is ipyparallel now a docs requirement?

[quaquel]

I am, in parallel, working on expanding on the MPI code. I noticed that I could reuse parts of the multiprocessing code in this. However, it also gave rise to circular imports. To resolve these, at a minimum, I needed to move all reused parts into a separate util module. Moreover, for convenience, I prefer to have related functionality in the same module and keep the modules rather short. Therefore, I moved all evaluators to their respective modules (i.e., multiprocessing, mpi, ipyparallel). The net result is a code base that is more cleanly separated, easier to test in isolation, and prepares for further updates to mpi and multiprocressing.

The prefix was ema, but that is not informative. I went with futures to indicate it has to do with parallization, but I am open to other suggestions.

The reorganization resulted in import problems that caused the docs to fail. I fixed it quickly by making ipyparallel required. I looked at other solutions, but because I am subclassing stuff from ipyparallel, I could not use the method level imports as used with mpi4py.

[EwoutH]

Thanks for the explanation.

Why do we need a prefix at all?

Edit: These are breaking changes right? As in it break current imports?

[quaquel]

If you don't, you can get namespace classes (e.g., em_framework.multiprocessing and multiprocessing).

No these are not breaking changes, because all relevant imports were available at the ema_workbench level already. It is only an internal reorganization.