zip_safe mode is broken

[nanonyme]

Copied from #189

without the zip_safe set to False when setuptools installs the library either using easy_install, setup_requires or install_requires these warnings get produced. The issue lies in the use of a CI service like Appveyor, the warnings are output using stderr and this triggers the build to fail.

zip_safe flag not set; analyzing archive contents...
comtypes.__init__: module references __file__
comtypes.client._code_cache: module references __path__
comtypes.client._generate: module references __file__
comtypes.client._generate: module references __path__
comtypes.server.register: module references __file__
comtypes.test.TestComServer: module references __file__
comtypes.test.TestDispServer: module references __file__
comtypes.test.__init__: module references __path__
comtypes.test.test_dispinterface: module references __file__
comtypes.test.test_findgendir: module references __path__
comtypes.test.test_safearray: module references __file__
comtypes.test.test_server: module references __file__
comtypes.test.test_urlhistory: module references __file__
comtypes.test.test_win32com_interop: module references __file__
comtypes.tools.codegenerator: module references __path__

[nanonyme]

This has been changed 12 years ago through https://github.com/enthought/comtypes/commit/04ae848a028b02171c3e66f8e1dfa99be0856312; before that comtypes generated modules in-memory for py2exe use case (like it's documented to do). This is no longer happening.

[nanonyme]

If the generation into memory is no longer supported at all, it should be removed completely from code and documentation. There's references to this still in comtypes codebase eg https://github.com/enthought/comtypes/blob/31d05e55ed67ebcd6e48fe52deb5bfea0c4cfb2f/comtypes/client/_generate.py#L142-L149

[nanonyme]

https://github.com/enthought/comtypes/blob/6fb440372bb03e3acece00b35cac87f2eddf7d69/comtypes/client/_code_cache.py#L87-L111

[nanonyme]

https://github.com/enthought/comtypes/blob/master/comtypes/client/_code_cache.py#L48-L64 in specific is the "new" (12 years old) behaviour that was never properly reflected throughout the codebase. comtypes now always either writes under user appdata or tempdir (depending on whether non-py2exe or py2exe respectively).

[nanonyme]

I think combination of https://github.com/enthought/comtypes/pull/189 + changing docs + removing the _generate.py code might be enough, really, to have some consistent end result. Seems the code in _code_cache while possibly not really meaningful is meant to be a last ditch effort so comtypes will still continue to function even though series of imports fails.

[nanonyme]

Looks like the code in https://github.com/enthought/comtypes/blob/6fb440372bb03e3acece00b35cac87f2eddf7d69/comtypes/client/_code_cache.py#L90 predates by far the code that permanently added https://github.com/enthought/comtypes/blob/master/comtypes/gen/__init__.py as part of the project. A lot of the code in _code_cache may be completely obsolete.

[kdschlosser]

Sorry about the delay.

I made some changes and created a branch. at the moment I do not have a build system set up to compile this thing using py2exe. If you happen to have something all set up then give this branch a shot and see if it corrects the problem wihtout having to set the zipsafe flag. It all depends on how the checking for __path__ and __file_\ are done.

https://github.com/kdschlosser/comtypes/tree/zip_safe_alternative

[nanonyme]

I do not and no worries, I do not personally even need py2exe.

[dmwyatt]

https://github.com/enthought/comtypes/blob/master/comtypes/client/_code_cache.py#L48-L64 in specific is the "new" (12 years old) behaviour that was never properly reflected throughout the codebase. comtypes now always either writes under user appdata or tempdir (depending on whether non-py2exe or py2exe respectively).

To be clear, it only uses appdata if the gen package location is not writable.

https://github.com/enthought/comtypes/blob/c8c065e47d44d6ae78a92a35c1429d7cefe6f8dd/comtypes/client/_code_cache.py#L44