Temporarily modify sys.path when executing example file in etsdemo

[kitchoi]

Context: Often demo examples are written assuming they are run from the command line. Sometimes these examples require importing components from outside of that file, e.g. here, here. However, when these examples are run from within the etsdemo, the sys.path is set for running the etsdemo application, and these imports would normally fail because they assume the local directory being on the path, which isn't true.

This inconsistency adds cognitive load to developers maintaining the examples: Developers need to keep in mind that the path is not what they typically expect.

The proposed solution would be to temporarily prepend to the sys.path the path of the directory containing the example file, similar to the behaviour when one runs the file from the command line.

This requires knowing exactly when the run context starts and ends, as the sys.path is a global state and it must be reverted back to how it was when the run context for an example terminates.

(Removing the demo tab will make determining the life-time of the run context a lot easier, see #1454)

[corranwebster]

Thinking about this, local imports from examples are inherently problematic.

For example, let's say we have two related examples, something like this:

example_1/
    main.py
    helper.py
example_2/
    main.py
    helper.py

In each case assume main.py includes an import helper statement.

Then even if we mess with sys.path to make the imports work, we have a problem that whichever is run first will cause sys.modules["helper"] to hold the contents of the local helper.py, and then any subsequent import helper statements will get that helper, not the intended local one.

Messing around with sys.modules is even more fraught than messing around with sys.path.

The only way to prevent this sort of problem is to run the example in a different interpreter (for simplicity, in a separate process, but 3.9 has subinterpreters which could also solve the problem).

[kitchoi]

Acknowledging that the double import trap is indeed a problem for some examples if they are run after another, the implementation of subprocess is not cheap, and it brings a whole loads of other restrictions. See #1466 for a rough comparison. A lot of the existing features in the demo application become difficult to achieve with subprocess.

Subprocess by itself does not solve the problem with Python path, but it does change how we should set the python path (i.e. instead of mutating sys.path as a list, set the PYTHONPATH environment variable).

(Sometimes I open an issue with a title that does not assume a particular action; but when I do that, others complain the issue isn't actionable. The title can be changed if we want to change plan. I hope the issue description has stated the problem alright...)