[Koha-devel] Location of plugins in @INC

[Fridolin SOMERS]

Mmmm tempting but dangerous indeed.

I'd say plugins in a software must be additions of features, modifying 
features is forking.

Best regards,

Le 11/11/2020 à 23:41, dcook at prosentient.com.au a écrit :
> I wouldn't say impossible to maintain, but that's a good point about competing plugins trying to override the same modules.
> 
> Your critique of my @INC idea would also apply to giving plugins access to the Mojolicious router though. Overriding via plugins is probably not a sensible solution.
> 
> I am somewhat familiar with Mojolicious plugins, and that's an interesting idea, although those should really be set at app startup time. (I have been wondering how we could improve the Koha plugin experience by getting all Starman workers to reload to include new plugin code...)
> 
> I think both the Mojolicious plugins and modifying @INC could be useful for sysadmins but probably not Koha end users - now that I think about it more.
> 
> Speaking of Mojolicious, feel free to add your CC to Bug 26791, Julian. I haven't posted my patches yet, but I'm sure your feedback will be useful when I do. I'm planning to replace the export.pl script with a Mojolicious controller. I just need to find some time to finish it off.
> 
> David Cook
> Software Engineer
> Prosentient Systems
> 72/330 Wattle St
> Ultimo, NSW 2007
> Australia
> 
> Office: 02 9212 0899
> Online: 02 8005 0595
> 
> -----Original Message-----
> From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Julian Maurice
> Sent: Wednesday, 11 November 2020 9:46 PM
> To: koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] Location of plugins in @INC
> 
> Le 11/11/2020 à 01:17, dcook at prosentient.com.au a écrit :
>> Hi all,
>>
>> I was talking about how we could override default Koha modules with
>> customized versions by just making sure those modules were located
>> earlier in @INC.
>>
>> That got me thinking… at the moment we put Koha Plugins at the bottom
>> of @INC, but we could actually put them at the start of @INC.
>>
>> They would be more dangerous as they’d be able to override any Perl
>> module… but they would also be more powerful.
> 
> More powerful, and quite impossible to maintain, as every change to the module would have to be done in the plugin as well :/ Also, two plugins overriding the same module... It just won't work.
> 
>>
>> In the context of a Koha where controllers are Perl modules (e.g.
>> Mojolicious controllers) rather than Perl scripts, a plugin could
>> override any controller in Koha. That could make for very powerful and
>> seamless customizations.
> 
> For this particular use case I think there are better options, like giving plugins access to the Mojolicious router, which allows to override some routes.
> Also note that Mojolicious has its own plugin system that can be used as well. For now the list of plugins used by Mojolicious applications is static, but it certainly can be made dynamic without much effort.
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France