Python plugin works in NPP 7.7 but does work in NPP 7.8 upward
-
@Stier-Hahn - currently trying
-
@Stier-Hahn
Yes, it is not found but then I do get -
and next window is
-
but npp 7.7 works.
-
I start to remember that I read some conversation about
security concerns regarding sideloading dlls. -
@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… -
If there is anything we can do to help let us know.
-
@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 pywin32 is installed sort of correctly as it works from python command line.
-
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 topath 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?? -
@Ekopalypse cool, thanks for advice, turned out to be pywin32_system32 not being searched for some reason
Apparently lookup path was (intentionally screwed up) modifiedI managed to fix my problem by placing pywintypes38.dll and pythoncom38.dll to NPP root