failure to compile with import NumPy AND pywin32 installed

[py2exe]

failure to compile with import NumPy AND pywin32 installed

[albertosottile]

To be honest, I have always used pypiwin32 and I had no issues embedding that module with py2exe. I'll investigate this issue but, in the meantime, could you try to use pypiwin32 instead and see what happens?

[urishab]

first time I hear about these issues with pywin32.
But you were right, simply installing pypiwin32 solves the problem.

[albertosottile]

TIL that pypiwin32 actually acts as a shim that just installs pywin32 itself, so when you install pypiwin32 you should actually have both. So, I do not understand what could have caused this issue.

Anyway, the issue hints to a mismatch between the file extension reported by the loaded module itself (.dll) and the expected extension for a python module library (.pyd).

At the moment, however, I am unable to reproduce this bug. I tried to pack the test script with both packages installed (pywin32 and pypiwin32) and after deleting the second, no bug. I also tried to include in the py2exe_test4.py script a module from the package (I chose win32pipe) but the packaging still works in both cases. The required pywintypes37.dll is always correctly embedded in the dist folder.

I guess that I could give it another look if you manage to reproduce the bug, otherwise I am going to close this. Thanks anyway for reporting it.

[urishab]

yes I also saw a requirement for pypiwin32 is pywin32
I tried and couldnt' reproduce the error anymore.
I guess it's because of pypiwin32 even though I use virtual environment

you can close it I guess

[urishab]

I just found out that I still get the exception when I launch the py2exe from my PyCharm using debug mode.
When I run it using Run mode there's no exception.
I have no idea why.

Installing pypiwin32 doesn't help.
It still fails with assert if I launch it in debug.

Reading the docs it seems that the assertion should work the same unless I specify the -O flag to python to ignore assertions but somehow it is ON by default.

In any case the py2exe succeds in building the executable and it runs fine so I don't see how the assertions makes a difference.
Perhaps there is another nuance that I'm missing with my test that would fail later. Not sure. Or perhaps the assertion is too rigid.

Not sure if this should be considered an issue though.

[albertosottile]

If I had to guess, I would say that the debug mode of PyCharm interferes with the libraries loaded by the packages and sought by mf3. It makes sense though that pypiwin32 did not solve the issue, because it literally contains no code.

In any case the py2exe succeds in building the executable and it runs fine so I don't see how the assertions makes a difference.

Is there any advantage in running a frozen executable built with py2exe when PyCharm was in debug mode? Otherwise, I would say to just avoid using this mode for freezing software. I am not a user of PyCharm, so I cannot be of much help here.

[urishab]

I just tested it and you're right. It has to do with the PyCharm debugger. The assertions are not disabled.

I wasn't trying to run a frozen executable in debug mode, rather the py2exe compilation process. That's useful to debug py2exe issues.

[albertosottile]

I wasn't trying to run a frozen executable in debug mode, rather the py2exe compilation process. That's useful to debug py2exe issues.

What are the extra data provided when running py2exe with PyCharm in debug mode?

[urishab]

I was using the debug mode to debug the OPCODE issue for example.
Just generally debugging a process is better than running it through.
Breakpoints, introspection, etc...