Dealing with plugin dependencies

[felixhayashi]

At this point, TiddlyWiki makes it already very easy to write plugins and in fact a whole lot of plugins are already written for TW5 and certainly there are more to come.

Thus, TiddlyWiki needs to organize its plugins more efficiently. Just to give two quick reasons:

• Each plugin should solve a single problem (unix style) which makes a modular dependency structure necessary. This makes it easier for plugins to be maintained.
• Especially Tiddlywiki is vulnarable when it comes to size. If two plugins use the same library, then they should share the code instead of increasing the wiki's size twice.

Maybe we can discuss some suggestions how we could deal with dependencies?

[felixhayashi]

How it is done in Debian

Debian packages use the following mechanism to create a dependency structure:

Each package comes with a depends field. In this field, all dependencies are entered comma separated and optionally with a depending version.

All packages are uploaded to a central repository.

If a user wants to install a package on a debian system, the installer queries a central repository for depending packages and if the user accepts, installs everything.

In its basics, this is also how all the other package systems work.

[felixhayashi]

While an automatic dependency resolver would be the non-plus-ultra, maybe for a beginning, it would be sufficient enough to visually inform the user, which plugin is related to which other plugin.

I recently added a TiddlyMap feature where it is possible to define which edges constitute the hierarchy in a graph. Consequently TiddlyMap calculates the hierarchy and displays it as a graph (felixhayashi/TW5-TiddlyMap#15).

Maybe we could use this to have a tiddlywiki dedicated for plugins that

• contains tiddlers that describe and link to plugins
• and relate these tiddlers with tiddlymap to
• eventually display these "depends on" relationships in a graph.

@tobibeer already has a great collection of plugins with their descriptions (of course other great collections exist as well), maybe this could be enhanced by adding a dependency graph?

- just an idea

[pmario]

There is already a dependents parameter, that is part of plugin.info files.
see: http://tiddlywiki.com/#PluginMechanism

[felixhayashi]

Hi @pmario,

There is already a dependents parameter, that is part of plugin.info files.

Why is it called dependents a plugin only knows what it depends on. It can never know who depends on it. Or am I misinterpreting the word?

Regardless of that, I am talking about how to actually make use of such fields and how we can achieve a modular structure that is visible to the enduser or is automatically solved when installing a plugin. At the moment all plugins seem exist rather isolated and do not share code...

[tobibeer]

imho, shared libraries should be encouraged as much as possible... as well as bringing shared code in the core

[felixhayashi]

imho, shared libraries should be encouraged as much as possible...

right, this has many benefits

as well as bringing shared code in the core

Yes, of course, if the majority of plugins depend on that. If the code is too special, however, I am more in favor of keeping it as a shared library plugin.

[tobibeer]

keeping it as a shared library plugin

should thus be part of the core repo, like those "core plugins", imho

Equivalent to...

$:/plugins/

...define:

$:/lib/

...for jQuery, Vis, FontAwesome, all the things emerging as dependencies, along with those helper utilities that enable this stuff in a TiddlyWiki context, e.g. the extensions mechanism I defined for FontAwesome

[Jermolene]

Maybe we can discuss some suggestions how we could deal with dependencies?

What are the circumstances in which dependencies of a plugin would be processed? The obvious answer is plugin installation and upgrading, but perhaps there's more to it.

One possibility is that dragging a link to a plugin with dependencies should include the dependencies in the drag operation (so that a plugin and its dependencies could be installed in one operation).

It would be fairly easy for upgrade.html to include dependencies when upgrading plugins.

It's worth noting that plugin installation still needs some attention. The present system of dragging the plugin tiddler itself (so that the JSON of the plugin is transferred in the drag and drop event) means that the file containing the link has to contain the entire plugin. That's starting to be a problem - upgrade.html is now over 5MB because it includes a copy of all the plugins.

We need to allow plugins to be installed via a new kind of link where only the URL of the plugin is transferred via drag and drop, and the target wiki loads the plugin itself from the provided URL.

Why is it called dependents a plugin only knows what it depends on. It can never know who depends on it. Or am I misinterpreting the word?

@felixhayashi I'm afraid that was a typo on my part.

It is currently only used by the plugin switcher mechanism; when a switchable plugin (ie a theme or a language) is selected, any listed dependent plugins are loaded too.

[felixhayashi]

What are the circumstances in which dependencies of a plugin would be processed? The obvious answer is plugin installation and upgrading, but perhaps there's more to it.

At the moment I cannot imagine another scenario. I will think about it.

One possibility is that dragging a link to a plugin with dependencies should include the dependencies in the drag operation (so that a plugin and its dependencies could be installed in one operation).

Yes. Going with this solution means that the wiki that offers the plugin also has to include all dependencies as well (which it usually does).

It would be fairly easy for upgrade.html to include dependencies when upgrading plugins.

upgrade.html? Didn't know that exists. Great!

That's starting to be a problem - upgrade.html is now over 5MB because it includes a copy of all the plugins.

That is why I thought to have a plugin tiddlywiki that only contains references. Then the linked site needs to include all dependencies for that plugin which is usually fine (as I said above).

We need to allow plugins to be installed via a new kind of link where only the URL of the plugin is transferred via drag and drop, and the target wiki loads the plugin itself from the provided URL.

Yes, exactly. This goes in the direction of an ajax mechanism that queries the link and saves the json response in the users wiki.

I'm afraid that was a typo on my part.

Oh ok.

[Jermolene]

upgrade.html? Didn't know that exists. Great!

It's the official way to upgrade to new versions:

http://tiddlywiki.com/upgrade.html

[pmario]

@Jermolene .. imo should be labeled "feature request"