~dmbaturin/soupault

4 3

Dependencies for plugins

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

I ran into a interesting issue today.

I am currently setting-up a new website, and wanted to reuse the
soupault configuration of soap.coffee/~lthms, minus certain plugins.

It turns out I removed one plugin, and let another which uses the
“after” options. In practice, it was not a “hard” dependency, rather an
optional one.

Maybe we could

  1. have a “before” option?
  2. distinguish between optional and “hard” dependencies?

What do you think?

Best regards,
Thomas
Details
Message ID
<410623cf-1a56-c07f-fcc5-26b329f9b4a5@baturin.org>
In-Reply-To
<20200301125425.yfss7dhmjq3sb6ab@ideepad.localdomain> (view parent)
DKIM signature
pass
Download raw message
Hi Thomas,

I've been wondering about it when I implemented dependency sorting. My
reasoning was like:

A "before" option can make configs easier to write, but it may also make
it harder to keep track of the dependency graph when reading that config
a month later.
I'm not categorically opposed to adding it though. It's should only a
small yak to shave: once you convert them to "after" option, you can use
it with the same tsort function.

As of soft dependencies, I'm not sure how much value they provide. Could
you give me an example of a use case where it's strongly desirable to
run one widget after another, but not _required_?
In my mind the distinction is binary: either there is a reason one
widget has to run after another (usually because it uses the output of
that widget for its input), or the order doesn't matter.
However, I may be missing something just because I don't have that such
use cases personally.

On 3/1/20 7:54 PM, Thomas Letan wrote:
> Dear soupault enthusiasts,
>
> I ran into a interesting issue today.
>
> I am currently setting-up a new website, and wanted to reuse the
> soupault configuration of soap.coffee/~lthms, minus certain plugins.
>
> It turns out I removed one plugin, and let another which uses the
> “after” options. In practice, it was not a “hard” dependency, rather an
> optional one.
>
> Maybe we could
>
>   1. have a “before” option?
>   2. distinguish between optional and “hard” dependencies?
>
> What do you think?
>
> Best regards,
> Thomas
Thomas Letan
Details
Message ID
<20200302065559.xl5cbv3oumlcmg7p@ideepad.localdomain>
In-Reply-To
<410623cf-1a56-c07f-fcc5-26b329f9b4a5@baturin.org> (view parent)
DKIM signature
pass
Download raw message
> However, I may be missing something just because I don't have that such
> use cases personally.

My use case is the following

Plugin A is the plugin which mark external links
Plugin B is the plugin which generates a revision table

Neither A nor B /need/ each other, but for their output to make sense if
they are together, B needs to run after A. So a soft dependency makes
sense here, I suppose.

That being said, removing the “after” dependency of B if you remove A
works too.

Thomas
Details
Message ID
<79dee364-65f4-06ab-2817-5af43c53061b@baturin.org>
In-Reply-To
<20200302065559.xl5cbv3oumlcmg7p@ideepad.localdomain> (view parent)
DKIM signature
pass
Download raw message
Oh, I see. Indeed, if you have a dependency chain like A → B or A → B →
C → ..., disabling widget A can cause cascade failures.

I'm not sure what will be a good balance between value for users and
added complexity.
My feeling is that referencing undefined widgets in a production config
should be considered a bad practice, while when messing up with the
config it's not too hard to comment out the "after" option of the widget B.

However, if you have an idea for a reasonably simple design of a soft
dependency feature, please share.

On 3/2/20 1:55 PM, Thomas Letan wrote:
>> However, I may be missing something just because I don't have that such
>> use cases personally.
> My use case is the following
>
> Plugin A is the plugin which mark external links
> Plugin B is the plugin which generates a revision table
>
> Neither A nor B /need/ each other, but for their output to make sense if
> they are together, B needs to run after A. So a soft dependency makes
> sense here, I suppose.
>
> That being said, removing the “after” dependency of B if you remove A
> works too.
>
> Thomas
Details
Message ID
<d3fea970-427d-8a95-d9bc-6a34b2679386@aoirthoir.com>
In-Reply-To
<410623cf-1a56-c07f-fcc5-26b329f9b4a5@baturin.org> (view parent)
DKIM signature
pass
Download raw message
Perhaps it would be easier to have the dependences someplace else..

[widgets.a]
something etc...

[widgets.b]
something etc...

[widgets.c]
something etc...

[widget-order]
psuedo-code... (because im not sure exactly how this could be 
implemented in toml)
   order = "a,c,b" (a is done then c then b)
   dependencies = ["c,a","b,c"] (c requires a, b requires c)

The advantage in this method is that we could see in one place all our 
dependencies and our order as well...