Plugin dependencies

I am in need of some swarm intelligence :slight_smile:

Since I started getting back into TiddlyWiki again I developed a few plugins. I also plan on releasing some of these soon but there is a hell of a lot of cleanup necessary for them to be useful.

However, over time some “structure” emerged for my plugins. Most of them use TiddlyWiki as a CR(UD) database and JSON tiddlers to prevent field proliferation/collision. Now most my plugins share common constructs like parameterized buttons and I would like to have some way to share them between plugins.

My idea was to create a separate plugin that serves as some kind of library. But as far as I can see there is no dependency mechanism in TiddlyWiki. So any presumed user of my modules would have to manually install the library together with the plugins.

Are there any best practices or is this the best option one has when it comes to reusing code?

1 Like

How do you build your plugins? … If you can create a plugin library, it is possible to define dependencies. So if 1 plugin is installed from the library, the second one will be installed too.

See: https://tiddlywiki.com/#Plugin%20Dependencies
eg: Some of the CodeMirror plugins have dependencies: https://github.com/Jermolene/TiddlyWiki5/blob/f87ab06414c921448b4a41bb38bc9739cf95555f/plugins/tiddlywiki/codemirror-autocomplete/plugin.info#L6

1 Like

Mario, you are a wealth of information :smile:

My process is pretty manual. I follow the instructions from the dev Wiki and then drag&drop the resulting plugin from the single file build over to the respective target wiki.

I do this mainly because I can not figure out how tiddlywiki.files works even though I asked about this in the Google Groups twice (1) (2). The reason I do this is that artifacts of Fossil get included into the result if I do not manually move them out of the build directory before…

Since I plan on releasing more than one plugin and they all work pretty similar (only tracking different things), a plugin library seems like a logical solution.

I set the parent-plugin field but how does the process work after this? When dragging the plugin over, the parent plugin is not taken alongside?

I’ll have to check that info in detail. …

There is an open PR, which should allow you to create and locally test a library server at GH. https://github.com/Jermolene/TiddlyWiki5/pull/6588 … but it’s not merged yet.

You may bump the PR at GH. …

It’s not parent-plugin it’s the dependants field that matters. … parent-plugin is only there to create a visual relation between a “main” plugin and plugin-addOns.

Ah so it is the other way around than what I need? Because the library is not dependant on those plugins do I have to specify all those (sub-)plugins in dependants? That would be a weird backwards thing for a library to do…

There is an example TiddlyWiki5/plugins/tiddlywiki/async/files at master · Jermolene/TiddlyWiki5 · GitHub

If you use the tiddlywiki xx --build command, it automatically uses everything that is part of the tiddlers or plugins folder. If in one of the plugins folder, there is a tiddlywiki.files file, it only uses the content, that is defined in that file. It’s a “all or nothing” behaviour.

This makes it possible to exclude plugins from being built, if an empty tiddlywiki.files file is used.

I did rewrite the Plugins docs: https://tiddlywiki.com/#Plugins:Plugins%20[[Installing%20custom%20plugins%20on%20Node.js]]%20PluginFolders to work for a video series I did lately.

That may help too:

2 Likes

Do you have a link to your repository. I don’t know Fossil, so I don’t know if that can be avoided. … BUT I’m pretty sure it should not involve manual changes to build plugins. …

It needs to be automatic. I build all my plugins and editions with 1 command npm run deploy from within the right repo. … Only the last step is manual. … Pushing it to GitHub … because I do want to do a final check.

Unfortunately not yet, but I plan on putting them up on my website in the coming days. However Fossil is pretty great when it comes to artifacts since there are only two:

  1. The repository itself which is a SQLite file (named whatever one chooses, ends in .fossil by convention)
  2. A .fslckout file that contains metadata for the current checkout (also a SQLite file)

Whilst #1 can be anywhere in the filesystem, #2 is always at the root of the checkout (so in my case the same level as plugin.info). However I prefer to have #1 at the root directory as well so everything is nicely together.

Amen to that. My whole infrastructure is automated. But since I build plugins rarely and never got tiddlywiki.files working, I bit the bullet and did it manually until now. However the number of plugins I wrote is now >3 and it gets stressful…

That shouldn’t be the case. The pluign directory should never be the one that contains “alien” meta data. It makes everythink more complicated.

If your directory structure would look like this: … Just an example

plugins/author/plugin-name

The plugins directory could be the root with all the meta data. Have a closer look at my videos, where I do explain the different possibilities with the TIDDLYWIKI environment variables. …

I think I was not clear about the layout, sorry for that.

Whenever I start a new plugin I create a new folder under /path/to/tiddlywiki/checkout/plugins/tjout/PLUGINNAME and there I create plugin.info and everything else. For every plugin I also create a new repository so I end up with this structure:

/path/to/tiddlywiki/github/checkout/
  |- plugins
  ||- tjout
  |||- PLUGIN1
  ||||- plugin.info
  ||||- readme.tid
  ||||- .fslckout
  ||||- ...
  |||- PLUGIN2
  ||||- plugin.info
  ||||- readme.tid
  ||||- .fslckout
  ||||- ...

Creating the .fslckout file at the checkout root is how Fossil works and there is no way I can prevent this. Pretty much the same game as .git for Git repositories. So the only “feature” that I need is for TiddlyWiki to ignore this file inside a plugin directory during build/loading.

This would not work since there can only be one file with the same name in a directory and every plugin would create a .fslckout file inside the plugin directory. Again the same reason one can not have two Git repositories checked out into the same directory because Git produces a .git at the root.

You should create a “feature request” … It may be possible to define a ignore-filter field in the plugin.info file. …

So to give tiddlywiki a regexp filter for files, that should be ignored. … I’d support this request