Finally solved/workaround'ed the issue...
Because of the new loader which doesn't branch off into new thread, then inspect.py was only getting the exe name when trying find the py file said exe was running(from 'inspect.stack()' call), and when then sent to tokenize.py for tokenizing, failed because was exe file and not py file. I checked manually with testing tokenizing the exe of the previous loader which also failed(python -m tokenize -e deluge.exe), so it was because of said missing to catch py file from exe file.
I looked into if could somehow patch inspect.py without giving bad results to other stuff, but then found out another solution/workaround actually instead.
The reason why only that plugin failed and not others I tested, was the failing plugin used an older deprecated way of enabling logging, which fired off that inspect > tokenize failing step, and when changing to the newer method, then those steps aren't run and hence doesn't fail.
Deluge's log.py source-file included following section additionally, I found by chance while reading through it:
Code: Select all
DEPRECATION_WARNING = """You seem to be using old style logging on your code, ie:
from deluge.log import LOG as log
from deluge.log import get_plugin_logger
This has been deprecated in favour of an enhanced logging system and both "LOG"
and "get_plugin_logger" will be removed on the next major version release of Deluge,
meaning, code will break, specially plugins.
If you're seeing this message and you're not the developer of the plugin which
triggered this warning, please report to it's author.
If you're the developer, please stop using the above code and instead use:
log = logging.getLogger(__name__)
I never gotten above deprecation warning message in my debug logs, which would have helped troubleshooting otherwise alot lol, and just found by chance when reading thru all the last referenced source-files in debug-log before the fail, and logging was the very last thing I troubleshooted/suspected and wasted much time on other parts i.e trying fix the failing inspect.py step, and before that, tokenize.py one. I never gotten that warning, because the preceding part failed just before reaching it.
When I changed the logging in plugin to new, non-deprecated style and rebuilt it, then it worked fine, so I uploaded it, plus I will submit a PR fixing this, to tote94's github repo soon, probbaly tomorrow.
Also, there is another popular fork of this plugin from jools, which features some extra and different options, including Sonarr/Radarr/Lidarr support etc(though his fork can only be configured from webui, but works from everywhere though), which has same issue, so also rebuilt that with fixed logging and uploaded, and again will submit PR soon to jools also, against his github repo, with otherwise same fix. Note, this last fork from jools currently doesn't run in petersasi's version, since missing a single file:
Lastly, as this isn't my project and i'm always somewhat affraid of overstepping my welcome here, or how to speak, then from now on i'll let petersasi alone handle things, which I know he's capable off anyway, so no reason for me interferring also, and so if needing my help for anything then ask me specifically, and i'll respond with my take on it also, if knowing anything about it of-sourse, that is
tote94's fork - fixed rebuild: https://gofile.io/d/MLbKV8
Jool's fork - fixed rebuild (As said, missing a file
to get working currently): https://gofile.io/d/qbAfEZ
Edit: Github doesn't support forking more than one fork at a time(of same original repo), which I could've worked around in hindsight, but anyway I think i'll just submit one PR at a time(not that good at git honestly), starting here with tote94's fork first: https://github.com/tote94/deluge-autoremoveplus/pull/2
Edit2: Submitted new ticket about this in meantime also on springjools github's issues section: https://github.com/springjools/deluge-a ... /issues/32
Edit3: Hmm, I got to think about other plugins possibly also has this deprecated logging, so would be nice not needing rebuild those plugins to be able to be used with unofficial installer and to not need submitting PRs etc, so I looked to see if I could patch log.py in deluge to not fail on this no-more. After knowing now what the issue actually is about, then I can google it now much more precisely, and I also read btw that exe's freezed with pyinstaller will also fail finding py from exe, through those inspect calls deluge also uses, so when official installer comes through, then will behave same as like with this new loader here I believe(so fail on same plugins), since uses pyinstaller for freezing. Anyway, there where some other code-changes suggested(not deluge related, but in general), and maybe that would work, I dunno, but honestly I used so much time on this already, so for now just slashed the failing code away and left the part where deluge logs a warning in log about the deprecated logging found and recommended a plugin rebuild, but atleast works then however. The code I slashed away was deluge trying to change the deprecated logging to the new logging, which it in the process failed in doing so.
If wanting to add this, then copy/paste in following new line e.g. just before the pycairo dll patch line, in both deluge build scripts(stable+dev):
Code: Select all
patch "%programfiles%/Deluge2/Lib/site-packages/deluge/log.py" < logging.patch
(Change to match your setup of-course, i.e. I believe to remember you use 'deluge' folder instead of 'deluge2' now, in your scripts).
'logging.patch' to go into "C:\deluge2\deluge-build" folder: https://gofile.io/d/ZDWEkK
just tested it working with vanilla plugins of autoremoveplus from tote94 and jools in my fresh rebuild of both deluge-stable and deluge-dev.