[IDEA] How to implement recursive installation of dependency plugins?

[dongrentianyu]

Is your feature request related to a problem? Please describe.

How should plugin dependencies be resolved if they are recursive? That is, one plugin depends on several other plugins, and some of those other plugins depend on other plugins, and then those plugins go on to depend on other plugins. Recursive cases such as this. This is indeed rare, but it was encountered in intention-tower-knowledge-graph plugin recently developed by @linonetwo.

The intention-tower-knowledge-graph plugin relies on a number of plugins, one of which is a calendar plugin that relies on another plugin, and another plugin that relies on another plugin. The order of these dependencies is itkg - calendar - pikaday - moment, with the result that when installing in TidGi, there is a problem with it not starting. See the relevant issues for details. tiddly-gittly/TidGi-Desktop#414 The single file version will only show that the calendar record is missing as a feature.

Describe the solution you'd like

I see in the documentation that lists are not parsed recursively. So I'm wondering if the recursive parsing is not done because there is no suitable filter, or if it's because considering plugin dependencies to install recursive parsing might cause problems for the stability of tiddlywiki?

In the former situation, it might be worth considering bringing in other filters to solve the problem. For example, the kin filter or the in-tagtree-of filter. Recursive dependencies are thus handled by recursive parsing.

My personal recommendation is to implement a plugin-dependent installation. Because in the future, we can build a uniform plugin library based on CPL, and of course others can publish their own plugin libraries. The interdependency of plugins can greatly reduce the development work of plugins. By calling on the functionality of other plugins, we can build on what we already have to achieve even more powerful functionality. This makes tiddlywiki not just a notebook, but an operating system in the true sense of the word.

Describe alternatives you've considered

Other solutions are available. For example, having the plugin developer check the dependency plugins in the dependency plugins and make it clear in the dependency plugins field. Another solution is to reduce recursion by making the dependency plugins that need to be recursively resolved into sub-plugins. Another solution would be to package the dependency plugins directly into the plugin, but this would make the plugin very large and prone to conflicts. The best solution is to implement recursive resolution.

Additional context

Another issue is how to control the version of dependent plugins. For example, one of the plugins that depends in intention-tower-knowledge-graph needs to be 0.5.0 and above. If the version in the user's wiki is below this point, there should be a prompt for the user to update the plugin. Or the installation of the dependent plugins should automatically update to this point. However I prefer to remind the user to update, make sure they are aware of what plugins are updated, and make a backup. If this needs to be discussed in a separate issue, please let me know.

I've also read some of the forum discussions and issues, but I don't feel that the issue has been explicitly raised or addressed.

e752ba7

[linonetwo]

And when upgrade this plugin, it doesn't auto install $:/plugins/xp/aggregation which is in dep list.

[pmario]

That's a tricky one, but worth considering.

This issue is discussed in different forms and shapes. Search for dependents here at GH.
List sorted from latest to oldest

• Call for thoughts on improving plugin handling #4263 -- which contains several other links
  • Proposal: The $ControlPanel provides possibilities for plugins to promote important content #4125
  • Move plugin library from modal to tiddler  #3208
  • Support plugins/publisher in wiki folders #1309
• Improve the plugin dropdown information #4086
• Add third-party plugins to the plugin library #1696 -- With a lot of thoughts in it
• Dealing with plugin dependencies #1345 -- probably one of first issues raised