Why does gPythonEngine go nil in Delphi with Python4Delphi?

Question

I'm not even sure how to describe this, nor simplify an example. I am trying register a Python module with my Delphi app that uses Python4Delphi, and am running into a strange scenario. Here is the general sequence of events.

Step 1. I create a form that loads the Python DLL and serves as a sort of console to see output from Python. This form gets created in a not visible nature, with my GUI providing a means to show it.

Step 2. At some later point, in a bpl I try to load a Python module doing something like the following:

  // first, extend the path with our current folder
  if not Boolean(SysModule.Path.Contains(folder)) then
    begin
      SysModule.Path.Insert(0, folder);
    end;

  // import the module
  handle := Import('pyWrapper');

Step 3. The call to SysModule.Path.Contains(folder) crashes in the call to the GetPythonEngine function, the source code of which is below:

function  GetPythonEngine : TPythonEngine;
begin
  if not Assigned( gPythonEngine ) then
    raise Exception.Create( 'No Python engine was created' );
  if not gPythonEngine.Finalizing and not gPythonEngine.Initialized then
    raise Exception.Create( 'The Python engine is not properly initialized' );
  Result := gPythonEngine;
end;

The problem I'm experiencing is that gPythonEngine is nil in GetPythonEngine when called from Step 2.

So I just realized the issue is that the SysModule.Path.Contains function calls GetPythonEngine, which basically returns a global pointer to the Python engine; however, that global is in the context of the main Delphi app, whereas my code shown in Step 2 is running in the .bpl file (aka a DLL). I believe the pertinent question, then, is thus the following:

How do I "share" the "Python engine" between my app and my .bpl packages? For other reasons, the architecture of my app is that it consists of an app and a set of .bpl packages (aka DLLs), many of these latter are essentially "plug-ins" to my main app, and so it isn't immediately obvious how to change that design.

I suppose one option might be to provide a "resource" to the .bpl that actually does the Python4Delphi calling - this just occurred to me while writing this - but that may open other cans of worms...