#109 Prevent LoadPythonServiceClass from importing non-services


The current implementation of LoadPythonServiceClass appends the target module's directory to sys.path.

This means that if the target module's name is shadowed by that of another module already on sys.path, that shadowing module will be imported instead, leading to a cryptic "Python could not find the service class in the module" error logged to the Application event log.

As an example, attempting to load the module "C:\Python27\lib\site-packages\pywinservice_example\test.py" loads the module "C:\Python27\lib\test\__init__.pyc" instead.

This patch changes the logic to insert the module's directory at the beginning of sys.path, then remove it after attempting to import the module.

The upside is that formerly shadowed module names (like "test.py") are now usable as service module names. The downside is that if the service module attempts to import another module with the same name, the service module itself will be imported instead.


  • Mark Hammond

    Mark Hammond - 2012-01-02
    • status: open --> closed-fixed
  • Mark Hammond

    Mark Hammond - 2012-01-02

    Thanks! But the patch doesn't compile as it references variables outside the scope they are declared in. Further, I'm a little reluctant to remove the directory from sys.path as there might be code out there that relies on it. So I've taken the change which inserts the new path at the start of sys.path and dropped the rest as commit 4178:0dc6321ba653


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks