[geeklog-devel] Plugin Version Control and Dependencies (featurerequest #0001154)

Rouslan Placella rouslan at placella.com
Thu Jan 27 16:54:35 EST 2011


I have a prototype implementation ready:
http://www.geeklog.net/forum/viewtopic.php?showtopic=91908

There still are a few issues with it and due to my inexperience with
version control all the code ended up in one 1400-line patch. But I
guess that would just be glad to receive some feedback about how the
plugin admin ended up, both in terms of appearance and functionality.
Thanks.

Take care,
Rouslan.


On Sat, 2011-01-22 at 09:50 -0500, Tom wrote:
> I like your array idea of 
> 
> // There can be multiple dependencies
> array( 'plugin' => 'socnet', '1.0.0' => '>=' ),
> 
> 
> This way if a plugin needs to it could state it only supports a plugin within a certain version range.
> array( 'plugin' => 'socnet', '1.0.0' => '>=' ),
> array( 'plugin' => 'socnet', '2.0.0' => '<' ),
> 
> Tom
> 
> -----Original Message-----
> From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Rouslan Placella
> Sent: January-22-11 9:10 AM
> To: Geeklog Development
> Subject: Re: [geeklog-devel] Plugin Version Control and Dependencies (featurerequest #0001154)
> 
> I started a bit of work on this and, yeah, I get it. And I also see that there is no need for that API call either. The plugins that use the new install, return install parameters through plugin_autoinstall_myplugin(). And they could just add the dependency information to the array that they normally return. Then it would be geeklog's responsibility to resolve those dependencies.
> 
> Rouslan
> 
> 
> On Fri, 2011-01-21 at 22:36 -0700, Vincent Furia wrote:
> > I'm with Randy. I think a single new API call should be sufficient.
> > 
> > 
> > -Vinny
> > 
> > On Fri, Jan 21, 2011 at 11:13, Randy Kolenko 
> > <Randy.Kolenko at nextide.ca> wrote:
> >         Just out of curiosity – why store anything in a table?
> >         
> >          
> >         
> >         The information required to install a plugin is easily pulled
> >         back by the plugin admin page by querying each plugin, and
> >         populated on the screen.  If a plugin is missing a dependency,
> >         don’t allow it to be installed and simply show the dependency
> >         information below the plugin and the associated status of each
> >         dependency (installed, disabled, missing etc).
> >         
> >          
> >         
> >         Like I noted before, we’ve done all this with Nexpro – the
> >         plugin page is all that really needs to be updated to support
> >         hiding the install button and showing the dependencies.  For
> >         Nexpro, each config file for each plugin has its own
> >         dependency list.  We do a version_compare and determine if the
> >         required plugin is there or not in the autoinstall.php file.  
> >         
> >          
> >         
> >          
> >         
> >         From: Rouslan Placella [mailto:rouslan at placella.com] 
> >         Sent: Friday, January 21, 2011 11:41 AM
> >         To: Geeklog Development
> >         Subject: [geeklog-devel] Plugin Version Control and
> >         Dependencies (featurerequest #0001154)
> >         
> >         
> >         
> >          
> >         
> >         I'd like to implement the dependency checks for geeklog
> >         plugins (bug #0001154).
> >         So below I wrote down some things that I think I'll have to do
> >         for this.
> >         Feedback? Suggestions? Opinions? Tips?
> >         
> >         Thanks,
> >         Rouslan.
> >         
> >         THINGS TO DO (or to keep in mind):
> >         * Create two database tables: 
> >         Store each plugin's dependencies in one table
> >         and each plugin's log from the latest install attempt in the
> >         other table
> >         
> >         TABLE plugin_dependencies
> >           pi_name      varchar(30) // Name of the plugin to which an
> >         entry belongs
> >           type         varchar(20) // 'geeklog', 'plugin', etc...
> >               require      varchar(30) // name of the required plugin
> >         (leave empty if $type is 'geeklog')
> >           version      varchar(20) // version of the required plugin
> >           operator     varchar(10) // type of comparison, e.g: ">=" or
> >         ">"
> >         
> >         TABLE plugin_install_log   // here we save custom messages
> >         that are generated when a plugin's install function is called 
> >           pi_name      varchar(30)
> >           type         varchar(20) // 'notice', 'info', 'warning',
> >         'error', etc...
> >           title        TEXT        // a title
> >           msg          TEXT        // a message
> >         
> >         
> >         * Create a new plugin API call:
> >         plugin_dependencies_pluginname()
> >             The plugin can return a two-dimentional array containing
> >         its dependency information and it's install log.
> >         Sample usage in the plugin would be:
> >         <?php
> >         // plugins/foo/autoinstall.php:
> >         ...
> >         function plugin_dependencies_foo()
> >         {
> >         ...
> >         return array(
> >         // This array says that the plugin 'foo' requires Geeklog
> >         version greater than or equal to 1.8.0
> >         array( 'geeklog' => 'core', '1.8.0' => '>=' ),
> >         
> >         // This array says that the plugin 'foo' requires the calendar
> >         plugin with version greater than 1.0.0
> >         array( 'plugin' => 'calendar', '1.0.0' => '>' ),
> >         
> >         // There can be multiple dependencies
> >         array( 'plugin' => 'socnet', '1.0.0' => '>=' ),
> >         
> >         // A message from the plugin regarding custom dependency
> >         checks
> >         // $type can be 'notice', 'info', 'warning', 'error', etc...
> >         array( 'message' => 'error', 'a title' => 'a message' ),
> >         
> >         // There can be multiple messages
> >         array( 'message' => 'info', 'another title' => 'another
> >         message' )
> >           
> >         /*  The settings will be saved to 'plugins_dependencies' table
> >         and
> >                             the messages to 'plugins_install_log'  */
> >         );
> >         }
> >         ...
> >         ?>
> >         
> >         * Introduce a function to update and resolve dependencies, as
> >         well as ensuring that the plugins are loaded in the correct
> >         order.
> >             Call this function:
> >         * when enabling/disabling a plugin
> >         * when installing/uninstalling a plugin
> >         * when changing plugin load order
> >         * when loading plugins?
> >         
> >         * Add the "plugin editor" to uninstalled plugins.
> >         * If there was an install attempt and it failed, show the
> >         entries from the "plugin_install_log" table there.
> >         * When warning about unresolved dependencies. Offer the
> >         options to: "try to resolve", "proceed anyway" and "cancel
> >         operation".
> >         * Add a clear_install_log($plugin) function and use it before
> >         each install so that there is only one log entry per plugin.
> >         * In the plugin admin, make it obvious when there is a message
> >         that was saved during the install and it can be viewed.
> >         
> >         * Show dependency information in the plugin editor for enabled
> >         plugins
> >         
> >         * Show the install log in the plugin editor for enabled
> >         plugins
> >             It'll probably say: "Installation was successful." only,
> >         most the time, but it could be useful to add custom
> >         information messages.
> >         
> >         * Keep backwards compatibility with all older plugins
> >         
> >         * Should be easy to extend to dependencies for databases
> >         (maybe even themes and blocks, too?).
> >         
> >         * Add a plugin_dependencies_* functions to the bundled plugins
> >         
> >         * Document everything better than this
> >         
> >         
> >         
> >         _______________________________________________
> >         geeklog-devel mailing list
> >         geeklog-devel at lists.geeklog.net
> >         http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> >         
> > 
> > 
> > _______________________________________________
> > geeklog-devel mailing list
> > geeklog-devel at lists.geeklog.net
> > http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel





More information about the geeklog-devel mailing list