Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Compose a plugin on demand
The default plugin package should be nothing more than package standard, a standardized format. Please, let’s keep it that way too.
As compiling goes, if you want to compile plugins with dependencies and what ever, you can. Building compilers ‘very’ exactly hard, especially if you just need to bundle data. For data, only thing you would need to is to bundle that said data in some storage format to the source code. Done.
Altho, if you just need to have configuration or some extra options, I would do them with individual optional plugins, be libraries or whatever, that extended the main plugin. On-demand compiled custom packages are cool, but what you end up with is horrible mess of where no one knows what the fuck they are actually using. It’s serious debugging hell.
As far as my work goes, I myself do some minimal extra ‘compiling’ processes. Basically it’s nothing more than joining and composing package from multiple separate source files with the help of MassPlugCompiler and rah_blobin.
I previously had rah_plugin_download that did on-demand packaging directly from the database, but dropped that since it was the stupidest idea of the year. Horrible mess. Made actual development complicated and the package and database format aren’t even 1on1.
Offline
Re: Compose a plugin on demand
Jukka, thanks for your reply.
Gocom wrote:
The default plugin package should be nothing more than package standard, a standardized format. Please, let’s keep it that way too.
Compiling (or whatever they are) directives would not invalidate the standard format, just add some php-neutral markup.
For data, only thing you would need to is to bundle that said data in some storage format to the source code.
Sure, but since most of us use Composer for plugin development, having some #import directive at hand would simplify things.
Altho, if you just need to have configuration or some extra options, I would do them with individual optional plugins, be libraries or whatever, that extended the main plugin.
I agree, and will probably end like that, but one has to care about naming conventions. In my case (pluggable calendars), I don’t know in advance which calendars will be installed, but would like to retrieve their names.
On-demand compiled custom packages are cool, but what you end up with is horrible mess of where no one knows what the fuck they are actually using. It’s serious debugging hell.
Agree too.
As far as my work goes, I myself do some minimal extra ‘compiling’ processes. Basically it’s nothing more than joining and composing package from multiple separate source files with the help of MassPlugCompiler and rah_blobin.
I will give them a try, thanks.
I previously had rah_plugin_download that did on-demand packaging directly from the database, but dropped that since it was the stupidest idea of the year.
It’s a new year. :)
Last edited by etc (2013-04-04 16:06:32)
Offline
Re: Compose a plugin on demand
This discussion is out of my depth but what if there is a standard plugin which calls for “libraries” which can be downloaded on demand. Would this make the process simpler?
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Compose a plugin on demand
Thank you, Yiannis, this could be a reasonable compromise. It gives the “main” plugin some control over its “components”, and technically should not be too complicated (but I leave it with devs). The end user wins in simplicity too. But, to be reliable, it requires a centralized permanent storage for plugins. If some day textpattern.org/ is rebuilt, this could be an interesting feature (for plugin updates too).
Offline
Re: Compose a plugin on demand
I have nothing against if someone wants to do custom packaged plugins, or if packaging features are added to a plugin, but I would rather not have any type of endorsed custom package compiling in the core projects, Textpattern or the actual plugin template. I personally don’t use ied_plugin_composer, so, I have no opinion to what you do with it. You can go crazy with it, as I care.
What this has gone from that is to about the plugin management, dependencies and updating. Which don’t work that well. Well, they don’t really suck, but are just nonexistent. There is no dependency management, no standards, no updaters, no noting.
…but I wouldn’t neither recommend us adding those to the core. We could never solve issues with third party libraries and dependencies. Truth is, you can’t use libraries with Textpattern plugin system since the plugins can just be a single file. The system does not comply well with ever growing array of PSR-0/1/2 projects. There is no namespaces, or autoloader mapping possibilities with the blob format Textpattern’s plugins use. It’s limited due to its simplicity. Only thing we could do with the plugin system is to have plugin dependencies… which doesn’t do anything.
Offline
Re: Compose a plugin on demand
Jukka, you are certainly right, things should be kept simple. What I meant in the previous post, is a core function to fetch plugins code from some uri and install it. This would allow a “master” plugin to contact some “repository” and install “library” plugins on user request, all in keeping trace of it, say in preferences. Master plugin would then know which libraries are (potentially) available.
Gocom wrote:
Only thing we could do with the plugin system is to have plugin dependencies… which doesn’t do anything.
Could be useful on delete.
Offline