~dmbaturin/soupault

6 3

Plugin autodiscovery

Thomas Letan
Details
Message ID
<20200302072937.uy23fekfi2sseye3@ideepad.localdomain>
DKIM signature
pass
Download raw message
Dear soupault enthusiasts,

I have been thinking about plugins recently, and I was wondering whether
or not an autodiscovery feature for Lua plugins could be possible.

This would work as follows. If a widget refers to a plugin which has not
been declared, then check whether or not `plugins/<name>.lua`
exists. From a soupault user point of view, I believe this could be
valuable.

What do you think?

Best regards,
Thomas
Details
Message ID
<98dda7fa-e6b6-6301-ce60-aba7038cdea5@baturin.org>
In-Reply-To
<20200302072937.uy23fekfi2sseye3@ideepad.localdomain> (view parent)
DKIM signature
pass
Download raw message
I was thinking about that too. It should be pretty easy to do in fact.
The original manual configuration mechanism can still be used for
overriding plugin names.
Perhaps introduce a configuration option like "plugin_discovery: bool"
that is true by default, but can be disables.

I think there should be an explicit plugin directory option, perhaps
even a list of directories.

[settings]
  plugin_dir = ["plugins",
"/opt/soupault1.9/usr/local/share/soupault/plugins"]

Implementation should be straightforward, take out the plugin loading
logic out of plugins.ml's _load_plugins function, then add a new case in
widget.ml's load_widgets.


On 3/2/20 2:29 PM, Thomas Letan wrote:
> Dear soupault enthusiasts,
>
> I have been thinking about plugins recently, and I was wondering whether
> or not an autodiscovery feature for Lua plugins could be possible.
>
> This would work as follows. If a widget refers to a plugin which has not
> been declared, then check whether or not `plugins/<name>.lua`
> exists. From a soupault user point of view, I believe this could be
> valuable.
>
> What do you think?
>
> Best regards,
> Thomas
Thomas Letan
Details
Message ID
<20200303191510.fvaesm2cnbb2lq4n@ideepad.localdomain>
In-Reply-To
<98dda7fa-e6b6-6301-ce60-aba7038cdea5@baturin.org> (view parent)
DKIM signature
pass
Download raw message
> I was thinking about that too. It should be pretty easy to do in fact.

I was hoping for a response like that!

I like the two configurations option you propose. I would suggest to
have `plugin_dir` initializes with three value (potentially easily configurable
at build time)

- ./plugins
- ${HOME}/.config/soupault/plugins
- /usr/share/soupault/plugins

and maybe /usr/share/soupault/plugins too

Another approach (maybe a *better* approach, actually) would be to
rely on an environment variable.

of course, this could still be overriden within the configuration file.

> Implementation should be straightforward, take out the plugin loading
> logic out of plugins.ml's _load_plugins function, then add a new case in
> widget.ml's load_widgets.

I will try to have a look later this week. No promises, though (:

Thomas
Details
Message ID
<909841b7-2d9f-3653-847b-96a7c9e88a55@baturin.org>
In-Reply-To
<20200303191510.fvaesm2cnbb2lq4n@ideepad.localdomain> (view parent)
DKIM signature
pass
Download raw message
>I would suggest to have `plugin_dir` initializes with three value
I would limit the default to ./plugins
There are BSDs that prefer /usr/local/share for third-party
applications, and then there's Windows.

>potentially easily configurable at build time
Dune can substitute variables at build time, but I haven't seriously
tried that feature yet.

>Another approach (maybe a *better* approach, actually) would be to rely
on an environment variable. 
>of course, this could still be overriden within the configuration file.

Right now there's an opposite approach to site_dir/build_dir variables:
you can override them with command line options.
See
https://soupault.neocities.org/reference-manual/#custom-directory-layouts
I think the same can be done for the new plugin_dir option.

If we are to allow using multiple dirs there, we'll have to use
different separators on UNIX and Windows (Windows uses ";" in its %PATH%
AFAIR, since colon is used for drive letters like C:).
That's easy to do at runtime using the Sys.win32 variable.

On 3/4/20 2:15 AM, Thomas Letan wrote:
>> I was thinking about that too. It should be pretty easy to do in fact.
> I was hoping for a response like that!
>
> I like the two configurations option you propose. I would suggest to
> have `plugin_dir` initializes with three value (potentially easily configurable
> at build time)
>
> - ./plugins
> - ${HOME}/.config/soupault/plugins
> - /usr/share/soupault/plugins
>
> and maybe /usr/share/soupault/plugins too
>
> Another approach (maybe a *better* approach, actually) would be to
> rely on an environment variable.
>
> of course, this could still be overriden within the configuration file.
>
>> Implementation should be straightforward, take out the plugin loading
>> logic out of plugins.ml's _load_plugins function, then add a new case in
>> widget.ml's load_widgets.
> I will try to have a look later this week. No promises, though (:
>
> Thomas
Details
Message ID
<7a683e4b-eed4-2d38-79d1-1601392553b5@baturin.org>
In-Reply-To
<98dda7fa-e6b6-6301-ce60-aba7038cdea5@baturin.org> (view parent)
DKIM signature
pass
Download raw message
As of 5bdf3bba
<https://git.sr.ht/~dmbaturin/soupault/commit/5bdf3bba9b4c8f0f22513538df4e16c43e5cd3fd>,
soupault supports plugin autodiscovery.

There are two new options in [settings]:

[settings]

  plugin_dirs = ["plugins"]
  plugin_discovery = true


It's possible to specify just one dir with plugin_dir = "plugins". If
more than one dir is specified, their order is also plugin lookup order,
i.e. if you use plugin_dirs = ["plugins",
"/usr/share/soupault/plugins"], it will first look in ./plugins, then in
the system dir.

If soupault sees a widget name that is not a built-in and isn't in the
list of explicitly configured plugins, it will look for a plugin in
those dirs. For example, if you use widget="frobnicate", it will look
for a file named "frobnicate.lua".

Unlike explicitly configured plugins, auto-discovered plugins _cannot_
override built-in widget names. A plugin file like "toc.lua" or
"insert_html.lua" will be ignored.

There is no support for plugin path environment variable yet.

The code is an imperative mess so far, but I'm building both
soupault.neocities.org and my own site without explicit plugins
configuration and it works fine for me. Testing is welcome.
Thomas Letan
Details
Message ID
<20200321105208.dku734qah6hgi7cb@ideepad.localdomain>
In-Reply-To
<7a683e4b-eed4-2d38-79d1-1601392553b5@baturin.org> (view parent)
DKIM signature
pass
Download raw message
Daniil,

This is a very good news! Thank you for taking my suggestion into
account.  I couldn’t find the time nor the motivation to do it myself,
unforunately.


> Unlike explicitly configured plugins, auto-discovered plugins _cannot_
> override built-in widget names. A plugin file like "toc.lua" or
> "insert_html.lua" will be ignored.

This looks like a good behavior.

> The code is an imperative mess so far, but I'm building both
> soupault.neocities.org and my own site without explicit plugins
> configuration and it works fine for me. Testing is welcome.

I will definitely try to modify my website configuration and see how it
comes. I am confident it will make the file less verbose and this is
great.

Thanks again for your work
Thomas
Details
Message ID
<9a991809-6d35-e0fe-2424-cbbb57f33875@aoirthoir.com>
In-Reply-To
<98dda7fa-e6b6-6301-ce60-aba7038cdea5@baturin.org> (view parent)
DKIM signature
pass
Download raw message
I've used this feature extensively... and it works great.