Changes between Version 33 and Version 34 of PadrePluginCookbookRecipie05


Ignore:
Timestamp:
08/26/11 19:15:36 (3 years ago)
Author:
bowtie
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PadrePluginCookbookRecipie05

    v33 v34  
    116116* draft needs tiding up 
    117117{{{#!text 
    118 12:05 bowtie     Alias_, Padre::Plugin POD, padre_interfaces, lists Padre modules and version numbers. 
    119 12:05 bowtie     1, is it upto date 
    120 12:05 bowtie     2, it appairs to me you only need, 'Padre::Plugin' => 0.nn, 
    121 12:05 Alias_     You need to declare everything you use 
    122 12:05 Alias_     So if you use Padre::Logger, you need to declare that 
    123 12:05 Alias_     If you do $plugin->main->some_method you need to do Padre::Wx::Main 
    124 12:05 Alias_     etc 
    125 12:06 Alias_     You declare the parts of Padre that you use 
    126 12:06 Alias_     So when we break compatibility in one part of Padre, ALL the plugins that use it aren't loaded, but ONLY the plugins that use it are disabled 
    127 12:07 bowtie     Alias_, but plugins still work and don't through any errors or warnings at present 
    128 12:07 Alias_     You THINK they work 
    129 12:07 Alias_     They MIGHT work 
    130 12:07 Alias_     But you can't know that 
    131 12:07 Alias_     This is about failure modes 
    132 12:07 Alias_     We have a choice about how we want plugins to fail 
    133 12:08 Alias_     1. Always have every plugin load, wait for each one to do something illegal in Padre and blow up, leaving it half-loaded or in some unknown state and maybe crashing PAdre 
    134 12:08 Alias_     2. Disable some plugins due to "compatibility" which really will still work, just in case one was using the specific part you changed 
    135 12:09 Alias_     In the first case, we have unknown and uncontrolled impact, and random side effects, any of which are potentially disasterous 
    136 12:09 Alias_     In the second case, plugin authors need to check they still work, bump the plugin's dependency hash past the change, and do a simple incremental release 
    137 12:10 Alias_     The second is much more responsible, and much safer when there's no firewall between the plugins and the core 
    138 12:10 Alias_     Firefox doesn't even give THAT much leeway 
    139 12:10 Alias_     Every plugin is automatically disabled, until they SPECIFICALLY test they still work 
    140 12:10 Alias_     We are at least doing piece-meal disable on a per class basis 
    141 12:10 Alias_     Which is more cpan friendly 
    142 12:11 bowtie     Alias_, ok, so the the the modules version will be that of the Padre version it was created against, hence all module version numbers should be the same? 
    143 12:12 Alias_     Usually yes 
    144 12:12 Alias_     But someone might have checked that one specific class hasn't changed in the place we care about further back 
    145 12:13 Alias_     Or one plugin might depend on another plugin 
    146 12:13 Alias_     And so on 
    147 12:13 bowtie     Alias_, I will add this to cookbook wiki then, ok 
    148 12:13 Alias_     But USUALLY they will all be the same 
    149 12:13 bowtie     Alias_, the POD shows diffrent versions 
    150 12:13 Alias_     Well, it IS theoretically possible 
    151 12:15 bowtie     Alias_, so hidden some whare in your brain is an padre-plugin api version v padre version numbers then :) 
    152 12:15 Alias_     api version is the same 
    153 12:15 Alias_     Padre::Plugin is just another class that the plugin "depends on" 
    154 12:16 bowtie     Alias_, from POD, Padre::Plugin - Padre plug-in API 2.2 
    155 12:16 Alias_     oh, that 
    156 12:16 Alias_     That's mostly just a way of mentally marking time 
    157 12:16 Alias_     It's not really any kind of official thing 
    158 12:16 bowtie     Alias_, yes it's confuses me 
    159 12:17 Alias_     Basically it just says "We've completely rewritten it twice, and made some big additions twice since then" 
    160 12:17 Alias_     It's for humans, not machines 
    161 12:18 Alias_     A bit like Padre::Task 2.0 
    162 12:18 bowtie     Alias_, on reflection I got that, but I don't know what the padre version was then, and if I use that version will a plugin be back compatable 
    163 12:19 Alias_     You don't have to 
    164 12:19 Alias_     You just say the most recent version of Padre you are SURE that the plugin works with 
    165 12:19 Alias_     And Padre itself tracks compatibility for you 
    166 12:19 bowtie     Alias_, I developed against :) 
    167 12:20 Alias_     our $COMPATIBLE = '0.43'; 
    168 12:20 bowtie     oops i -> ie 
    169 12:20 Alias_     See that? 
    170 12:20 Alias_     That's in Padre::Plugin 
    171 12:20 Alias_     So at a guess, the last time I broke compatibility for ALL plugins was likely 2.0 landing 
    172 12:20 bowtie     Alias_, POD shows 0.29 
    173 12:20 Alias_     Which means 2.0 probably arrived around about 0.43 
    174 12:23 bowtie     Alias_, ca I do perl dev -t Class::Name, Class::Name2 
    175 12:23 Alias_     Nope 
    176 12:23 bowtie     only one :( 
    177 12:25 bowtie     Alias_, all modules used by a Plugin that are not part of Padre core should be in sub plugin_disable 
    178 12:26 bowtie     even if required 
    179 12:26 Alias_     All plugin modules should be 
    180 12:26 Alias_     Don't unload third party modules 
    181 12:26 Alias_     You have no idea if anything else needs them 
    182 12:27 bowtie     Alias_, you mean Mouse for example 
    183 12:27 Alias_     right 
    184 12:27 Alias_     Only unload the plugin's own modules 
    185 12:29 bowtie     Alias_, ok if a Plugin over loads sub plugin_icon 
    186 12:30 * azawawi  home & 
    187 12:35 Alias_     You can overload pretty much anything you like 
    188 12:36 bowtie     Alias_, you are so happy it must be your un-Birthday again :), thanks 
     118bowtie 
     119        Padre::Plugin POD, padre_interfaces, lists Padre modules and version numbers. 
     120        1, is it upto date 
     121        2, it appairs to me you only need, 'Padre::Plugin' => 0.nn, 
     122Alias 
     123    You need to declare everything you use 
     124        So if you use Padre::Logger, you need to declare that 
     125        If you do $plugin->main->some_method you need to do Padre::Wx::Main 
     126        etc 
     127        You declare the parts of Padre that you use 
     128        So when we break compatibility in one part of Padre, ALL the plugins that use it aren't loaded, but ONLY the plugins that use it are disabled 
     129bowtie 
     130        but plugins still work and don't through any errors or warnings at present 
     131Alias 
     132        You THINK they work 
     133        They MIGHT work 
     134        But you can't know that 
     135        This is about failure modes 
     136        We have a choice about how we want plugins to fail 
     137        1. Always have every plugin load, wait for each one to do something illegal in Padre and blow up, leaving it half-loaded or in some unknown state and maybe crashing PAdre 
     138        2. Disable some plugins due to "compatibility" which really will still work, just in case one was using the specific part you changed 
     139        In the first case, we have unknown and uncontrolled impact, and random side effects, any of which are potentially disasterous 
     140        In the second case, plugin authors need to check they still work, bump the plugin's dependency hash past the change, and do a simple incremental release 
     141        The second is much more responsible, and much safer when there's no firewall between the plugins and the core 
     142        Firefox doesn't even give THAT much leeway 
     143        Every plugin is automatically disabled, until they SPECIFICALLY test they still work 
     144        We are at least doing piece-meal disable on a per class basis 
     145        Which is more cpan friendly 
     146bowtie 
     147        ok, so the the the modules version will be that of the Padre version it was created against, hence all module version numbers should be the same? 
     148Alias 
     149        Usually yes 
     150        But someone might have checked that one specific class hasn't changed in the place we care about further back 
     151        Or one plugin might depend on another plugin 
     152        And so on 
     153bowtie 
     154        I will add this to cookbook wiki then, ok 
     155Alias 
     156        But USUALLY they will all be the same 
     157bowtie 
     158        the POD shows diffrent versions 
     159Alias 
     160        Well, it IS theoretically possible 
     161bowtie 
     162    so hidden some whare in your brain is an padre-plugin api version v padre version numbers then :) 
     163Alias 
     164        api version is the same 
     165        Padre::Plugin is just another class that the plugin "depends on" 
     166bowtie 
     167        from POD, Padre::Plugin - Padre plug-in API 2.2 
     168Alias 
     169        oh, that 
     170        That's mostly just a way of mentally marking time 
     171        It's not really any kind of official thing 
     172bowtie 
     173        yes it's confuses me 
     174Alias 
     175        Basically it just says "We've completely rewritten it twice, and made some big additions twice since then" 
     176        It's for humans, not machines 
     177        A bit like Padre::Task 2.0 
     178bowtie 
     179        on reflection I got that, but I don't know what the padre version was then, and if I use that version will a plugin be back compatable 
     180Alias 
     181        You don't have to 
     182        You just say the most recent version of Padre you are SURE that the plugin works with 
     183        And Padre itself tracks compatibility for you 
     184bowtie 
     185        ie developed against :) 
     186Alias 
     187        our $COMPATIBLE = '0.43'; 
     188        That's in Padre::Plugin 
     189        So at a guess, the last time I broke compatibility for ALL plugins was likely 2.0 landing 
     190bowtie 
     191        POD shows 0.29 
     192Alias 
     193        Which means 2.0 probably arrived around about 0.43 
     194bowtie 
     195        can I do perl dev -t Class::Name, Class::Name2 
     196Alias 
     197        Nope 
     198bowtie 
     199        only one :( 
     200        all modules used by a Plugin that are not part of Padre core should be in sub plugin_disable 
     201        even if required 
     202Alias 
     203        All plugin modules should be 
     204        Don't unload third party modules 
     205        You have no idea if anything else needs them 
     206bowtie 
     207        you mean Mouse for example 
     208Alias 
     209        right 
     210        Only unload the plugin's own modules 
     211bowtie 
     212        ok if a Plugin over loads sub plugin_icon 
     213Alias 
     214        You can overload pretty much anything you like 
     215bowtie 
     216        you are so happy it must be your un-Birthday again :), thanks 
    189217}}} 
    190218