The status of the python plugin

[axxie]

While trying to develop a plugin using python I’ve made the following observations:

1. The python plugin is off by default. This is in contrast to all other plugins, except farftp.
2. Consequently it is not included into .deb-packages
3. There is no mechanism to automatically load python scripts on far2l startup (or am I missing something?)
4. (minor) There is no way to add plugin menu item just for editor. If it is added to plugin menu for editor, it will be present in the plugin menu for panels.

These observations led me to the conclusion that python plugin is not 100% ready for production use.

@m32, could you please clarify the intended use for the python plugin?

I mean, are end users supposed to use some python scripts with the help of this plugin or it is just for quick creation of PoC before implementing plugin in C?

[m32]

far2l is marked beta, so saying something is not ready for production is true. Apart from me, I don't see any interest in the development of this plugin among others, so I develop it myself in my spare time. Far2l-api is complete and mostly used, vfs is usable (temppanel), dialogs work. Editor - I didn't write any extension for it, so I don't know if it works. Generally speaking, you can write plugins ... only which ones? gvfs, adb, ..., sqlite, ... Problems will arise, you just need to have an idea and time. Pluginmanager - I did not want to load everything I can, so for my needs I only load what I need at the moment :), PR is welcome.

[axxie]

Thanks for the answer! I really wanted to know the relative "productionness" of the plugin compared to that of far2l itself. If the issues are not part of the design, I will spend some time fixing them, sure.

[axxie]

Ok, item 4 should be withdrawn: the far2l API doesn't allow single plugin to have different menus in panels and editor. This is not an issue for standalone plugins, but it prevents python plugin from creating separate menus depending on settings in scripts. In theory the situation could be improved by analyzing all scripts and placing PF_DISABLEPANELS if there are only non-panel plugin scripts. However, this would not solve the issue in general case.

[m32]

It's not exactly what you say, upanel.py only appears in DISKMENU, udialog.py in PLUGINSMENU. The idea is that each plugin selects the places where it should show up and that's what the openform = ['where to show', '...'] variable is used for.

[axxie]

You are right in this, but I was talking about panels and editor exactly. Unfortunately, the plugins menu is common for panels, editor and viewer. Separate plugin controls appearance of its items in the plugins menu by using PF_DISABLEPANELS, PF_EDITOR and PF_VIEWER flags. Python plugin cannot do that, because it may have one script loaded that wants to appear in plugins menu in editor, and another script that wants to appear in plugins menu in panels.

[m32]

this line ? Info.Flags = ffic.PF_EDITOR | ffic.PF_VIEWER | ffic.PF_DIALOG I treat it as a place reservation, then each plug tells me where it will show up. Well, unfortunately, it must be different as you write, you have to check the plug's flags.

[m32]

ping: @axxie @elfmz @unxed

I wrote another plugin (adb) and I have some comments:

• far2l definitely stops being a lightweight file manager after including python plugin
• python should not be installed in far2l directory structures (security/maintability)
• pythonplugin should be able to compile with a different version of python than the one available at the time of farl2 compilation
• different systems have different python libraries
• after installation in the /usr subdirectory, users do not have the right to update python or to install their own plugins
• after installation, users will also be able to choose their own version of python and install their own packages from pypi

It seems to me that the python plugin should be removed from the farl2 repository, and only installed by those who need it during self-compilation.

[elfmz]

Even while its in main repository - its off by default - i.e. only those who want it - have to enable it. There is another idea to make option to selectively disable even installed plugins.

[sancoder]

For Gentoo users who has system wide USE=python this plugin is being built (and failing to do so). Not sure if it's Gentoo's problem or this project but I would +1 for @m32 comment higher. "Original" Far used lua, and that's what should be the choice for plugin developers. Bringing python into Far project looks like overkill.