[Plugin] YaRSS2 - RSS plugin with GTKUI support

[cdmichaelb]

Rename the egg to include 'py3.11', or alternatively omit any py-version. This plugin is one of the few where deluge's semi-recent fix(deluge 2.0.4+), to ignore python versions('pkg_resources.Environment(python/platform=none)'), doesn't work, so need continue these meassures(rename). Not sure if because of the embedded deps or what honestly, and isn't a regression neither.

Edit: Just for completeness, it's 'pkg_resources.require("YaRSS2")[0]' triggering this error, used a few places i.e. 'load_libs()' of 'yarss2/__init__.py' and 'get_version()' + 'is_running_from_egg()' of 'yarss2/util/common.py'.

I attempted this method, and now YaRSS2 both shows up, and the checkbox remained enabled. But I'm not getting the YaRSS2 config tab.

[mhertz]

When not having ability to configure an enabled plugin, then presumably because running in thinclient mode without plugin available on client-side(only server), so place a copy of the egg file in e.g '~/.config/deluge/plugins'.

If not that, then please retest with restarting deluge/container, and enable debug-logging to see if anything relevant, and tell us which docker image, and host OS you're on.

[coffeee]

I'm sorry if this questions has been asked and answered, a million times, because it seems like it has. But, I'm new to Deluge, and it's got me a bit bamboozled.

Information on my setup:
Running Ubuntu 22.04 server
installed deluged, deluge-web & deluge-console packages (running headless)
Python version 3.10

I think I have deluge and the webui setup correctly; I've been following this guide by addictivetips to get me through the initial setup.

My problem is that I'm trying to install an RSS2 plugin for deluge, but it's giving me trouble. I went and grabbed the python3.10 egg from here at bitbucket and placed the egg file into plugin directory for deluge. What happens is, a YaRSS2 plugin option shows in the preferences/plugin menu, and is checked off. But, clicking the install button doesn't work, and I don't get an RSS2 tab in the preferences menu.

Additionally, on startup of deluge-web, I get the following error message, that only occurs when I have the python3.10 egg inside the plugin directory:
11:24:03 [ERROR ][deluge.pluginmanagerbase :153 ] Unable to instantiate plugin 'YaRSS2' from '/home/chooch/.config/deluge/plugins/YaRSS2-2.1.5-py3.10.egg'!
11:24:03 [ERROR ][deluge.pluginmanagerbase :1512] cannot import name 'YaRSS2' from 'yarss2.webui' (/home/chooch/.config/deluge/plugins/YaRSS2-2.1.5-py3.10.egg/yarss2/webui.py)
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/deluge/pluginmanagerbase.py", line 148, in enable_plugin
instance = cls(plugin_name.replace('-', '_'))
File "/home/chooch/.config/deluge/plugins/YaRSS2-2.1.5-py3.10.egg/yarss2/__init__.py", line 65, in __init__
from .webui import YaRSS2 as _pluginCls
ImportError: cannot import name 'YaRSS2' from 'yarss2.webui' (/home/chooch/.config/deluge/plugins/YaRSS2-2.1.5-py3.10.egg/yarss2/webui.py)

I'm sure I'm missing quite a few fundamental approaches to deluge which are causing me to have these issues, but if I could get pointed in the right direction, that would be a great help.

[mhertz]

Unfortunately yarss2 doesn't feature webUI management support currently, and there is a bug I see with regards to your posted error message as you correctly found. I made a fixed build and uploaded underneath, but when fixed, then it only will avoid that error message, and let you now enable/disable from webUI if wanted, and show webUI preferences page merely stating "The YaRSS2 plugin must be managed through the GTK UI client.", so not really anything important, but regardless.

YaRSS2-2.1.5.egg

Btw, for feature reference, then please post yarss2 related questions/feedback to it's official forum thread thanks.

Edit: Merged threads.

[shinger]

When not having ability to configure an enabled plugin, then presumably because running in thinclient mode without plugin available on client-side(only server), so place a copy of the egg file in e.g '~/.config/deluge/plugins'.

If not that, then please retest with restarting deluge/container, and enable debug-logging to see if anything relevant, and tell us which docker image, and host OS you're on.

This thing i have experienced it in the past. Is there a possibility to have the following feature. I for example always do a wget directly on the server to get the plugin and then go fix the permissions. If the plugin is activated on the server, that it automatically downloads it also to your desktop where you have the thin client installed (plugins directory). I mean i does not need to be activated by default, but for the people like me in the future i want to automate the process of installing/configuring Deluge using Ansible. So if i just open the thin client automatically the plugins are downloaded from the server as well and placed in my plugins directory.

I mean it is not like the daemon and thin client that they can differ, the plugin must be the same version as well, so a sort of a automatic sync with the first connection to the server, would not be a big deal right?

That would be one less headache and one less problem people come to the forum for support.

[mhertz]

I see your point of-course shinger, and surely would lead to less support requests as is sorta confusing, but i'm not sure how I feel myself about it honestly this concept of copying over files automatically, and possibly needlessly, I mean if only needing core-functionality, then not needed having copy locally. Also clients connecting as "thinclients" can be full blown official clients, like GTK-UI and console-UI, but also smaller client scripts just quickly polling something or whatever. If always being dependent upon certain configuration in your client, then might as well have it already installed as per standard I kinda too feel, and if needing multiple recreated setups then a recreation script or whatever can be used easily, e.g. I install deluge like that always(curl/wget plugins etc). I'm not sure it's good idea copying over plugins willy-nilly if not needed e.g. connecting from web-UI and the plugin in question doesn't have web-UI support even(granted could hardcode it in GTK-UI only, as you infer I think, and just me using the broader meaning of thinclient here), or if have 10 plugins then all 10 copied over, regardless needing client-side configurability or not - I see the idea obviously, but sorta like the flexibility in self-choosing myself.

Granted i'm just sharing my opinion and isn't knowing what the official stance is about this subject, as merely a regular forum member myself.

There is a function in the deluge API, upload_plugin(), though which only currently does the reverse i.e. copy from client to server, when selecting install plugin from client.

Anyway, I will just reiterate for others, to avoid confusion from me, that when connecting to server without having plugin on client-side, then it's still enabled and used, but just not able to be configured locally, but runs on core(on server) fine still, e.g. if was some rss downloader or whatever, then downloads still happening fine regardless. Then if having the plugin also locally in own config dir, then local configurability gets further enabled, if needing that, e.g. I wouldn't bother having locally if not needing such functionality specifically. Also this local configurability gets enabled automatically when plugin found locally and need not be enabled specifically. Also can be different version numbers, and python version numbers, though if dependent on specific new functionality, then obviously need match accordingly. Ohh sorry, I just came to think about that it's not just configurability it adds, but also any possible UI changes added e.g. in GTK-UI, and only core plugin otherwise.

Anyway as said, see the point and idea

[shinger]

I see your point of-course shinger, and surely would lead to less support requests as is sorta confusing, but i'm not sure how I feel myself about it honestly this concept of copying over files automatically, and possibly needlessly, I mean if only needing core-functionality, then not needed having copy locally. Also clients connecting as "thinclients" can be full blown official clients, like GTK-UI and console-UI, but also smaller client scripts just quickly polling something or whatever. If always being dependent upon certain configuration in your client, then might as well have it already installed as per standard I kinda too feel, and if needing multiple recreated setups then a recreation script or whatever can be used easily, e.g. I install deluge like that always(curl/wget plugins etc). I'm not sure it's good idea copying over plugins willy-nilly if not needed e.g. connecting from web-UI and the plugin in question doesn't have web-UI support even(granted could hardcode it in GTK-UI only, as you infer I think, and just me using the broader meaning of thinclient here), or if have 10 plugins then all 10 copied over, regardless needing client-side configurability or not - I see the idea obviously, but sorta like the flexibility in self-choosing myself.

Granted i'm just sharing my opinion and isn't knowing what the official stance is about this subject, as merely a regular forum member myself.

There is a function in the deluge API, upload_plugin(), though which only currently does the reverse i.e. copy from client to server, when selecting install plugin from client.

Anyway, I will just reiterate for others, to avoid confusion from me, that when connecting to server without having plugin on client-side, then it's still enabled and used, but just not able to be configured locally, but runs on core(on server) fine still, e.g. if was some rss downloader or whatever, then downloads still happening fine regardless. Then if having the plugin also locally in own config dir, then local configurability gets further enabled, if needing that, e.g. I wouldn't bother having locally if not needing such functionality specifically. Also this local configurability gets enabled automatically when plugin found locally and need not be enabled specifically. Also can be different version numbers, and python version numbers, though if dependent on specific new functionality, then obviously need match accordingly. Ohh sorry, I just came to think about that it's not just configurability it adds, but also any possible UI changes added e.g. in GTK-UI, and only core plugin otherwise.

Anyway as said, see the point and idea

So if i understand correctly. It is because of multiple issues this is not possible. Python version of both systems can differ, which would cause compatibility issues, i was thinking of maybe then that the thin client just reads the *.egg files remotely, but deluge version (thin client and daemon can differ which can cause compatibility issues (bugs etc).

These issues i can understand and i also 100% agree to it. Is there then the possibility that there is a like conditional statement.

IF thin-client version EQUAL TO daemon (remotely off course) version
AND Python version locally IS EQUAL to daemon (remotely off course) THEN use *.egg plugins remotely (enabled plugins only off course).

So you don't have to download the *.egg files, but just use the remote ones. In case if off course some would differ, then just ignore and leave it to the user to figure it out or download things manually. This solution is making the definition "thin client" even more accurate. No more messing with Windows, Mac, Linux thin clients issues. Just make sure your thin client and daemon run the same version and same python version is used, the rest will be taken care off.

It could be off course that i am asking too much as i am not aware of the complication it brings with it, but i try to think of solutions to make Deluge more "You install it and it works kind of thing". Because really everything is there already..python, deluge, plugins..we just have to be creative with it. If out of the box it does not work, then probably you messed up something and go fix it.

[mhertz]

Sorry buddy, i'm not the best at explaining myself, and to long-winded often etc additionally, and actually didn't even think of that i.e. issue with different python versions if such "copying-to-client" functionality was implemented, but indeed is a great point. All the stuff I said, was just merely personal preference things mostly, and not real issues, and as said I don't know the official stance on it i.e. if just haven't gotten to it yet, or if not feeling like good idea, who knows. If daemon and client can connect even, then already at supported versions(same major versions), and then just left the python version as you raise, though deluge ignores this actually now after deluge 2.0.4+ mostly, except in select few plugins(like yarss2, though only one I know like this) as includes some code incompatible to the fix applied for this, and main issue of if the devs even wanna do it, which as said I don't know. Also just to hammer down one last time, as not sure how good I phrased it, for others reading I mean, is that let's say have labelplus and yarss2 installed on server, then if not on client, then still autolabel-rules of labelplus used, and RSS-fetched downloads of yarss2 happening fine, despite not plugins existing locally on client, and so then just missing ability to e.g. righclick and label torrents manually or edit rss rules etc, which the local copy would have enabled if available(and need not be enabled in that case, as will be done automatically if found).

Anyway interesting discussion and point raised, thanks buddy, appreciate you thinking out of the box for the help of community, and sorry can not really answer in any official way.