As I am still trying to figure out how to get the most value out of TiddlyWiki and my Zettelkasten, I need to preserve my ability to rapidly make changes to my tooling. Worrying about backwards compatibility, upgrades, supportability, and changing things so they work well for other users and not just me would require a significant portion of my development time and motivation, and I don’t have that time to give at the moment. If I tried to supply these things, I wouldn’t be able to publish this at all. (Ordinarily I would just keep the tools to myself until they were a bit more mature, but I have gotten so many curious people casting jealous looks at my public Zettelkasten that I’m making an exception.)
I wonder would could be done to make this easier?
I’m definitely feeling this myself, that making any kind of edition is hard.
Is running under NodeJS and checking individual tiddlers into git the recommended method?
The extreme fluidity of TW makes it harder to nail down a distributable version.
Are there any known or theorized methods for making this easier?
Am I actually asking how to make plugins easier?
I did find @joshuafontany’s JSON Mangler / CSV import / export tiddlers as a plugin of shadow tiddlers to be very interesting.
I don’t know that there is a recommended method for end users to create editions. The benefit of using git is version control which isn’t directly tied to editions.
At its simplest, drag and drop plugins into a single file TiddlyWiki, add/create tiddlers in it and you have an edition.
I maintain two editions: one for some colleagues and one for a close circle of friends. What I have personally found easiest is to think of my editions as a set of versioned plugins. So an empty TW + a list of plugins at their specified versions equals my editions. All tiddlers that go into the edition that are not a part of other plugins, comprise their own edition specific plugin(s).
The challenge for me was managing plugin updates in a manner such that updating a single plugin doesn’t create an incompatibility with the other plugins. To get around this I’ve deployed my own update/plugin library mechanism for users to easily update those editions when I make changes. It helps significantly that these are end users with no real idea of what TW is and not doing any tinkering on their own. I still have to think twice before making changes that are beneficial for me personally as they will impact everyone else as well.
Also, the number of plugins in the editions can start to get high enough to be intimidating to the casual TW user. Especially when you have a lot of components shared between plugins, which therefore end up in their own utility plugins. This also makes it difficult to publish the various component plugins individually for others to use.
You can easily create plugins from the browser as well using Tinka if you aren’t interested in using version control, which is the main benefit from having a separate file per tiddler.
Lastly, I can completely relate to this part of what @sobjornstad says:
This pretty much sums up why I don’t plan to publish the WebDAV wiki farm setup, and why Streams development is dead in the water at the moment apart from fixing any bugs that get reported, and why I focus on contributing to the core instead.
When you have extremely limited time to devote to TW, it is difficult to find the balance between deriving value and maintaining interest for yourself versus trying to give back to the project. I have probably erred too far towards the latter in the last 12 months and my motivation has suffered as a result.
Better tools, facilities and infrastructure for development work that isn’t geared towards the core but rather in the realm of plugins and editions would help significantly. However, I appreciate that for a small project with limited resources, setting that up in itself would be a considerable challenge with uncertain returns.
This turned into a long and somewhat rambling post but hopefully there is something of value to others in here.
I’m a bit of an idiot. My experience of TW is that @jeremyruston is uber-aware of backwards-ability. And has been conscientious in preserving what we have had since 1622.
Which is fine, but I think @boris might be coming at this from a slightly different angle (jump in if I’ve misunderstood, @boris).
When a wiki (edition) is designed from scratch to be an “edition”, I think it likely to be a lot easier to make the edition and be “clear in your head” what’s what.
However, realizing later, “hey, this could be an edition!” presents you with a different set of problems, not all of which are obvious or even “visible” at the exact same time.
Either way, I find @pmario’s bundler plugin to be the answer to all my prayers, in this regard. With a simplistic (though perhaps lengthy) filter, my entire grab-bag of system tiddlers and plugins can be transferred to a virgin TW so easily it makes me smile every time (almost every day) I use it.
I have a few “quick-fix” tiny bundles (like “todays-changes”) and one large “everything” bundle (600+ tiddlers) that represents my “edition”.
One of the key things I’ve added to the mega-bundle is a “Purge list” – anything that has been relegated to the deprecation bin gets flagged right after import of the bundle.
This is pretty much where I find myself. I wish I could do more but the greater proportion of my time has to go elsewhere not only because the on-ramp is too slow/steep, littered with irritating little problems that cost a disproportionate amount of time.
I guess that’s what I was looking for in part, which once again is more on the power user / site builder side than pure developer tool, which is great.
Yep, this is a problem I have been contemplating as well and do not have a good solution for. Ideally I want to specify a third party plugin as a dependency and have my TW build process pull that in for me (ideally at the version specified).
For the purpose of creating an edition, I think you would also be OK to just install third party plugins by drag and drop and let them live in the tiddlers folder as JSON files on node.js or just as they are in a single file wiki.
Distributing Editions is an interesting area to think about as well. We don’t really have a recommended mechanism for distributing an edition. The two common options are to either offer an empty single HTML file, or a drag and drop button that transfers the payload for the edition. Both these approaches would work with third party plugins installed by drag and drop, avoiding the need to obtain their source code.
I will use a hypothetical example of a Fission Edition to describe one way in which editions could be distributed using the plugin mechanism, assuming the existence of a community plugin library that consolidates plugins from various authors.
Imagine that the Fission Edition consists of the following plugins:
EditCompText
FileUploads
FileUploads-Fission
Relink
FissionEdition (where this plugin is just a container for all the customizations you want to make that aren’t a part of other plugins).
Assuming that the FissionEdition plugin specified all the other plugins as dependencies by listing them in the dependents field, and all of these plugins were available via the same library, getting a new Fission Edition would be as simple as starting with a fresh empty wiki and installing the FissionEdition plugin from the library. All dependencies are automatically installed if they exist in the same library. This is how my editions are distributed but I have had to create my own plugin libraries and a mechanism to update them to back the editions.
Yes you can also do all your customizations directly in the browser by creating tiddlers and eventually use Tinka to pack all those tiddlers into a plugin. Distributing customization tiddlers as plugins makes it easier to push updates later on as plugins have versions and updating support in the core.
I am not very familiar with Bundler but the difference might be that plugins are natively recognized by TW whereas bundles are not.
You might try Peru, which bills itself as “a generic package manager for including other people’s code.” It lets you specify remote Git repositories and choose where to check out the code, but you only check in the Peru config file and ignore the rest of the code, so you don’t have to mess with submodules and stuff like that.
I use it for managing my TW and Vim plugins, among other things, and it works great.
Yeah I think the main issue is that the general TW plugin culture barely uses GitHub basics.
Mostly because so many interesting things get built in site builder land!
Peru is interesting, thanks for the link!
And finally — realistically if I track down a plugin on GitHub with no changes in the last 4-5 years, it’s going to be up to me to update it as needed!
Which of course is also a credit to TW’s long compatibility standards.
At the moment “bundler” doesn’t support creating plugins. The intention of “bundles” was that they should contain deletable content.
I personally think it’s much less work to delete stuff, that I don’t need, than to find scattered content that I need to include. … That’s why bundles create “standard” tiddlers.
On the other hand bundles can contain plugin-tiddlers aside with content-tiddlers, which makes it easy to “quick start” personalised editions.
It would be possible to add some buttons to the bundler, to create “plugin” output. … BUT I did avoid it, since imo Tinka does a good job already.
