[Geany-Devel] Proxy Plugins Update

[Thomas Martitz]

Am 12.07.2014 01:35, schrieb Lex Trotman:
> On 12 July 2014 09:25, Matthew Brush <mbrush at codebrainz.ca> wrote:
>> On 14-07-11 01:25 PM, Thomas Martitz wrote:
>>> 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.
>>>
>> If they're not justified, then why not provide upstream with a patch that
>> lowers them to minimum version required?
>>
>>> 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?
>>>
> Thomas,
>
> As I understand it you only need to bundle peas to be able to add the
> backward compatible loader?

Yes.

>
> If that is going to be for a limited deprecation period (say two
> release periods after the peas version is released) then it is
> reasonable to argue that the changes to libpeas are Geany specific,
> for a limited period and not worth pushing upstream.


The changes would be very geany specific, although the first one 
(supporting plugins that are not described by a .plugin file) can 
perhaps be made generic in some way. But the loader is always going to 
be highly Geany specific, and I don't think it would be accepted by 
upstream, seeing that they even dropped a java script loader that is not 
app-specific.

But yea, but I didn't ask yet either. This is in part because the last 
mailing list activity is from 2012 which didn't receive any response.

I'd like to remember you about another point: Even if libpeas would 
accept all our modifictions like tomorrow, Geany realistically couldn't 
depend on it for the near future anyway (too new). By the time we can 
depend on it, i.e. when it lands in the current enterprise distros (REHL 
will probably only have it by RHEL 8), we probably don't even need to 
modifications anymore. This is the main reason that I don't think it's 
worth even trying to push the changes upstream: we wouldn't be able to 
use that upstream for a few years, and once we can we don't need these 
changes anymore.

Best regards.