Python plugin works in NPP 7.7 but does work in NPP 7.8 upward

[Ekopalypse]

@Stier-Hahn
Yes, it is not found but then I do get

[Ekopalypse]

and next window is

[Ekopalypse]

but npp 7.7 works.

[Ekopalypse]

@Stier-Hahn

I start to remember that I read some conversation about
security concerns regarding sideloading dlls.

[Stier Hahn]

@Ekopalypse so, I’ve tested my minimal plugin build in 7.8 with python37.dll inside plugin dir and it works.

My question from the top of the thread has been solved.

Thank you very much!

ps

I still need to check if my main plugin will be working…
Struggling to upgrade third-party libs and other dependencies…

[Ekopalypse]

If there is anything we can do to help let us know.

[Stier Hahn]

@Ekopalypse you are doing great job , thank you !

ps
I came across a next roadblock , that’s more a pywin32 issue.

See https://github.com/mhammond/pywin32/issues/1658

May be you would have a hint how to troubleshoot that. as that seems to be sort of related to dependency lookup process.

In a nutshell I’ve NPP plugin linked against boost::python which loads at startup some initialization python code. And it’s was working fine under py 3.7 and npp 7.7.

Finally ( with your help) I managed to upgrade npp from 7.7 to 7.9
and partially from winpython 3.7 to winpython 3.8.

My NPP python plugin is loaded at startup, but execution of initialsation python scripts fails to import win32api.
Embedded python wrapper is working fine ( I guess ) as import os / import sys and other simple code is working inside my plugin.

I’m using win py 3.8 and latest pywin32 ( 300)

[Stier Hahn]

@Stier-Hahn pywin32 is installed sort of correctly as it works from python command line.

[Ekopalypse]

@Stier-Hahn

there is an additional
...\AppData\Roaming\Python\Python38\site-packages
path when used by the command line.
Maybe give it a try to add it to your sys.path from embedded python.

Do you know procmon ?
It could be used to see what npp and your plugin tries to load with a filter set to path contains whatever

If importing pywin32 failed with unable to load dll
then one of those

can not be found I guess.
python38 shouldn’t be the problem but pywintypes38.dll might be in this additional path I’ve mentioned earlier??

[Stier Hahn]

@Ekopalypse cool, thanks for advice, turned out to be pywin32_system32 not being searched for some reason

Apparently lookup path was (intentionally screwed up) modified

I managed to fix my problem by placing pywintypes38.dll and pythoncom38.dll to NPP root