Hi Jeremy,
> But there is no special version handling on import for plugins that don’t
> carry a version number. So if for some reason you don’t like the version
> checking, just don’t include a version number field.
>
I'm sorry, I should have tested that.
Are you suggesting that there is a requirement for a type of plugin that
> doesn’t show up in control panel?
>
I guess, I'm not. It's possibly more "conventions" than requirements.
That’s the first time you’ve mentioned a requirement for recursive plugins.
> Why is it important? As it happens, the plugin mechanism could be extended
> to do it, but I’d really like to understand why - it seems like a
> horrendously inefficient way of packaging most things.
Sorry, I keep on editing my already long posts for clarification and then
forget that you possibly only receive the original post via email.
Presumably that's not a good practice. Anyhow, *it is important* whenever
you want to bundle up literally anything, including plugins, as for the
use-cases mentioned above:
- including an entire wiki in another wiki, as the OP
- apps / app scaffoldings / workflows / components
- complex themes
- plugin bundles
- user preferences, in terms of plugin setups
- content bundles, e.g. "help" that come with plugins
- etc...
But that’s barely anything to do with the plugin mechanism! You’re just
> talking about a very specific improvement/alteration to the repackplugin
> function.
I tried to establish what it takes for using the plugin mechanism to create
and use the kind of bundles described.
I hope it is clear now that the above mentioned requirements are not met,
> as of today. At least, there appears to be no existing plugin-type workflow
> available to cater for either.
But they are! And have been from the beginning.
But Jeremy, we cannot bundle plugins in plugins. We cannot just bundle up
tiddlers (in terms of leveraging the shadow tiddler mechanism) without them
being called plugins (of type *plugin*). And, sorry, I did not know that by
(whatever means of ) removing any created version field we can actually
deactivate the version check mechanism.
I’m sorry, I’ve lost track of what you mean by “above”!
Allow me to repeat:
1. no versioning requirements
- turns out we already can, by removing any created version number
- ideally we could instruct *repackPlugin* not to set a version
2. be able to bundle any tiddlers, including other plugins
- this is mostly what's missing and, to me, warrants a new
*plugin-type*
3. no deletion of constituent plugin-tiddlers when performing
*repackPlugin*
- you appear to put that into a different bucket, even though it's a
crucial part to the bundling process
- ideally, I'd want an option that allows me to instruct this method
to not do that
4. to have "bundles", or whatever we call them, show up in the plugin ui
but not under the "*Plugins*" tab
- since they are plugins by nature but should not be of
*plugin-type:plugi
*which should be reserved, imho, for well scoped single-purpose
plugins, not arbitrary, even ad-hoc bundles that may even contain third
party child-plugins
Best wishes,
— tb
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/57ea0563-4f4c-4b29-b77f-d1d5c1725b1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
