[Geany-Devel] Proxy Plugins Update

[Thomas Martitz]

Am 11.07.2014 22:03, schrieb Colomban Wendling:
> Le 07/07/2014 18:48, Thomas Martitz a écrit :
>> [...]
>>
>> In my last post I've followed the approach of proxy plugins, aka pluxys.
>> This approach is based on geanypy and implements a plugin API for
>> plugins to act as proxy. I have mostly finished that (including an
>> trivial example pluxy), and ported geanypy to this framework. The result
>> is that with this approach I was successfully able to load python
>> plugins with the core, including access to the plugin API, to the extend
>> that geanypy allows plus keybindings via a new (experimental) API call.
>> I think this should cover almost everything you would want for python
>> plugins.
>>
>> Since with that work you can successfully load python plugins I consider
>> this approach workable.
> Nice.
>
>> Now that the pluxy approach is in the final stages I went onto toying
>> with libpeas.
>>
>> [...]
>>
>> There are three areas of problems with libpeas before we can adapt it,
>> two of which I could already solve in a fork.
>>
>> [...]
> If using libpeas really requires having a modified version of it lying
> in our code, I'm not convinced it's a great idea.
>

It's because we require modifications to it for backwards compat, this 
way we could maintain ABI and API stability across a transition to 
libpeas. We can drop it from our source after the transition period 
and/or convince upstream to accept rather geany-specific code (unlikely).

Another issue is that upstream libpeas tends to require recent glib/gtk 
versions even when not justified. The fork would allow us to lower the 
glib/gtk requirements.

libpeas is tiny, and is not actively developed (one can consider the 
project mostly done). So I don't think it's a big deal really. On the 
other concept of libpeas does provide a lot of benefits so it's worth it 
IMO.

What alternatives can you propose?

Best regards.