Textpattern CMS

#1 2008-07-23 16:39:33

net-carver

Archived Plugin Author

Registered: 2006-03-08

Posts: 1,648

Plugin 'Requires' meta entry...

Would any plugin authors find a ‘requires’ entry useful at the top of their txp plugins? The basic idea would be to have the txp plugin install routine evaluate the ‘requires’ condition when the plugin is installed and then warn the user if the plugin will work or not in their install.

You could express requirements about textpattern, php, mysql and other plugins like this…

$plugin['requires']='php > 5.0 ; textpattern >= 4.0.5 ; plugin.wet_peex *';

Where the ‘*’ operator would mean ‘is available’ / ‘any version’.

There would also be the ability to check for php and apache modules in a similar dotted format…

$plugin['requires']='apache.mod_negotiation * ; php.gd * ';

From my pov, such a feature would…

• provide a common precondition mechanism for plugins
• remove the common precondition checking code from the plugins to the core
• encourage the specification of such preconditions
• help avoid plugins breaking live installations

I have a working implementation of this and can supply a patch — but want to determine if…

1. there is anyone else would find this useful
2. to accept feedback on the idea
3. to find out what the dev team think

Many thanks in advance for your time.

---

— Steve

#2 2008-07-23 17:43:47

ruud

Developer Emeritus

From: a galaxy far far away

Registered: 2006-06-04

Posts: 5,068

Website

Re: Plugin 'Requires' meta entry...

As a Debian user, I certainly enjoy the advantages of a good dependency checking system when installing software… but I also know how much energy is spent in keeping all those dependencies up-to-date and I very much doubt this would work well for TXP plugins. For example:

• If a plugin is written for TXP version X, it should (IMHO) work with the same PHP versions that TXP version X supports.
• Claiming a plugin works with all TXP version greater than version X simply doesn’t work. Sometimes plugins break in newer TXP versions. It’s not something you can predict for future versions.
• Dependency checking is difficult. Some plugins have drop-in replacements with different names. ZCR has a whole range of language plugin add-ons that are mutually exclusive. By hardcoding the dependencies in such cases, new add-ons cannot be released without also updating the plugin that requires them.
• What if people use Lighttpd or IIS, which may have the same features as an Apache module, but which isn’t detected as such.