Attempt to fix a sporadic bug in the exex test (#1041)
Attempt to fix a sporadic bug in the exex test (#1041)

Sometimes this test has been failing with an exception such as:

ipyparallel/serialize/serialize.py:198: in unpack_apply_message
    f, bufs = deserialize_object(bufs, g)
ipyparallel/serialize/serialize.py:158: in deserialize_object
    newobj = uncan(canned, g)
ipyparallel/serialize/canning.py:438: in uncan
    return uncanner(obj, g)
ipyparallel/serialize/canning.py:491: in <lambda>
    CannedObject : lambda obj, g: obj.get_object(g),
ipyparallel/serialize/canning.py:200: in get_object
    __import__(self.module)
parsl/tests/sites/test_local_exex.py:12: in <module>

where a DFK is initialised inside an exex worker - something unexpected
and unsupported.

Occasionally this spurious DFK initialisation (or, rather, probably
one initialization per core) shows up a race condition in the DFK
workdir creation code, giving the above error.

When running tests within pytest, the test module is imported as part
of deserialising something, which doesn't seem to happen(?) when
running outside of pytest.

This test loaded a global DFK at module import (something which
is OK to do in a top level workflow module, but not in library code,
which this module then effectively is if imported deep inside the
runtime).

This commit changes the global DFK creation to happen when using
pytest setup_module, so that pytest will cause the DFK creation when
initializing the module, but other imports of the module will not
get a DFK.
Parsl/parsl,Parsl/parsl,Parsl/parsl,Parsl/parsl