[Geany-Devel] Proxy Plugins Update

[Matthew Brush]

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?
>

Not bundling it in the tree :)

You haven't really given any good reasons why we need to fork libpeas 
that can't be solved by working with upstream to make the things you 
want to do possible (ex. exposing the needed headers/types). AFAIK some 
distros[1][2] hate when apps bundle libs like this and might require at 
least that we tried to work with upstream before we can get exceptions 
about embedding current/active/readily-available system libraries in our 
tree.

Alternatively, couldn't you do the Peas extensions completely separate 
from the existing loader code (as in my "peas" branch), and then make 
the plugin manager GUI homogeneous so that it's the same experience for 
plugin users? Without trying to munge our old loader together with the 
Peas loader, all of your problems would fall away, IIUC (or at least 
make a new different set of problems :)

Cheers,
Matthew Brush

[1]: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
[2]: https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles